Wednesday, March 19, 2014

Happy 8th Birthday Java!

It's been another longer journey but yesterday, exactly two years, seven months, and eighteen days after the release of Java 7 we now have production-ready builds of Java 8 available for download! This new major release contains several new features and enhancements that increase the performance of existing applications, make it easier to develop applications for modern platforms, and increase maintainability of code. Here is a brief overview about my personal highlights.

What's new overall?
Several areas of the language itself, profiles, security, JavaFX, tooling, scripting, Date and Time, concurrency and a more or less lengthy list of things changed or got added. More than 8.000 bugs and features have been addressed and be incorporated into this release. The complete list can be found in the official release-notes.

Java Mission Control 5.3
One of the highlights is the new Java Mission Control release. It is bundled with the JDK and comes with a separate list of enhancements in it's own release-notes. Find the complete documentation as part of the official Java SE 8 documentation.

Compact Profiles
The newly introduced profiles enable reduced memory footprint for applications that do not require the entire Java platform. The javac compiler has a -profile option, which allows the application to be compiled using one of the supported profiles. The three are additive layers, so that each Profile contains all of the APIs in profiles smaller than itself. The compact profiles feature is useful in small devices with less hardware power.
And yes, I am personally still totally frustrated that Jigsaw will probably never see the light. But I am happy to be proven wrong on that.

Java Date-Time Packages
Thank you Stephen! Thank you for this great piece of work. TimesTen is the new Date and Time API in Java 8. Clear, Fluent, Immutable, Extensible. There are two basic ways to represent time. One way represents time in human terms, referred to as human time, such as year, month, day, hour, minute and second. The other way, machine time, measures time continuously along a timeline from an origin, called the epoch, in nanosecond resolution. See the official tutorial for more examples and usages.

Good Bye PermGen!
Removal of PermGen. Full stop. It's gone! YES!

Security Enhancements
More and stronger Algorithms, TLS 1.2 default and further enhancements.

Java 8 is co-bundled with the Nashorn, which is an implementation of the ECMAScript Edition 5.1 Language Specification. See the user-guide for all the details.

Happy 8th Birthday Java!
Congratulations to everybody involved. Especially the Adopt-OpenJDK community which was driven by the London-Java-Community and supported the Date-Time efforts by providing tests.

Thursday, March 13, 2014

JavaOne CfP 2014 - Open for Business

This time of the year. Finally. It was about time. The 2014 JavaOne Call-For-Papers opened a few days back. And it is going to be a great one. Plenty of changes upcoming and it will have a huge focus on community speakers.

The rolling acceptance process from last year is back, so submit early!

A quote of mine sneaked into the advertising emails ;)
There is a new dedicated track for Agile development this year, making a total of nine Java tracks.  This year's tracks are:

• Clients and UI
• Core Java Platform
• Internet of Things
• Java Virtual Machine Languages
• Java and Security
• Tools and Techniques
• Server-Side Java
• Java in the Cloud
• Agile Development

The call for papers closes April 15th at 11:59 p.m. PDT  and there is no time to waste. The best of the best speakers from the Java/JVM ecosystem will be there and if you look at the submissions from 2012 you see that most of the content comes from the community. As usual, speakers will receive a complimentary pass to JavaOne with an accepted talk.
Go ahead and submit some awesome talks!

Abandon Fish! Migrating from GlassFish to JBoss or TomEE

I'v been a bit busy lately writing and reviewing stuff and didn't really had the chance to wrap up content for my blog. But things will change again and I am truly looking forward to that. So this is just a small reminder about one of the latest things I've been working on. RebelLabs published their latest report yesterday and it was my pleasure to put some efforts into it.

Since a while the GlassFish community is a bit uncertain about the future of GlassFish and many developers are looking into alternatives. There are plenty of recommendations backed by vendors and evangelists. And nobody looked into the details and problem areas. It was time to change that and a bunch of people put together their thoughts and experiences about what it takes and which would be the best migration target. The outcome is the Abandon Fish! report. You can get it for free (at least for the price of your email if you want the PDF) and it contains all about the history of GlassFish, an assessment of the political situation and influencing parameters and a solid analysis about the different containers and reference implementations used on different servers. The outcome are 34 pages, beautifully designed and easy to read which guide you through the first steps and give you very good hints on what to expect when trying to migrate your existing applications from GlassFish to WildFly or TomEE.

Thursday, February 20, 2014

"Continuous Enterprise Development in Java" by Andrew Lee Rubinger and Aslak Knutsen

I've been doing book reviews since some time now. But this is a special one. Back at JavaOne I ran into Aslak and Andrew and we had a chance to talk about their latest book project which has been floating around the interwebs since some time now.

Take a use-case approach to Enterprise Java development, and discover how to program more effectively. This practical book shows you how to perform continuous development, using a testing platform the authors built with the JBoss community. Known as Arquillian, this platform acts as the missing link between testing and development.

Andrew Lee Rubinger and Aslak Knutsen demonstrate how testing is the very foundation of development—essential for learning and critical for ensuring that code is consumable, complete, and correct. Whether you’re learning a new technology, debugging broken behavior, or laying down new code, Arquillian helps you document your project in the form of test cases.

Book: Continuous Enterprise Development in Java
Language: English
Paperback: 222 pages
Release Date: February 20, 2014
ISBN-10: 1-4493-2829-6
ISBN-13: 978-1-4493-2829-0

My Interview
Thanks for taking the time talking to me. We know each other since a while mostly from the Arquillian Project. It was the first to have a ton of documentation beside the awesome testing features.
Now you are writing a book "Continuous Enterprise Development in Java" which is about testable solutions with Arquillian. Let me ask you some questions about it.

What is the book all about? Putting guides together? What was your motivation?

In building out the Arquillian Test Platform, we set out to make full-scale integration testing approach the simplicity offered by unit tests.  Historically, Enterprise Java has been cumbersome to validate in what we call a “real” runtime: one that closely mirrors how it will run in production.  Spring and Java EE both offer POJO programming models which facilitate the re-use of our business objects outside a backing container, but we feel strongly that testing outside of the proper context can lead to misleading results.  Only when we plug everything in together can we be assured that things are working properly, and that applies to both the code you write *and* the code you rely upon from an application server.
As our community grew we continued to build out extensions and guides for Arquillian which would offer instruction not just in applying Arquillian tests to Java EE, but explaining some ways to piece together Enterprise Java applications as a whole.  While there are plenty of books about a single technology - Andrew has written a revision of “EJB 3.1” from O’Reilly, for example - we found that our users were coming to us to learn about Java EE in general.  This grew our mindset that “testing is development”, and the book is a natural extension of the guides we’d built off for Arquillian.
In short, we felt that there wasn’t a book which broke down a complex Java application into layers and explained how they were wired together and tested, so we wrote one.

You're using a comprehensive example app throughout the book. What is GeekSeek all about and why did you choose it?

From the onset, we knew we wanted our examples to be more than simple toys.  We wanted to address the concerns of a developer charged with delivering a complete application: how do you validate asynchronous components?  What’s a good way to expose a true RESTful interface for your services?  How may a UI call the services layer and how do we ensure the rendered response is correct?  How do alternative domain models factor into the equation; should they be used and if so, when?

So we needed some single application which would allow us to address the use cases we wanted to explore without feeling like we were overengineering for the sake of example.  It turns out that the excellent Lanyrd service, one we use to track our own conference involvement, provided many of the features we needed to cover, so we created the GeekSeek example application as an homage of sorts to Lanyrd.

It was extremely important to us to deliver a self-proving example: one that could be downloaded and built by a user, but also ran in our own continuous integration environment and lived on a production server, so GeekSeek is the manifestation of that idea.  As developers we learn by doing, and this application is proven to work by nature of its being served up live.

Did the book help improve Arquillian? It is the best kind of "eat-your-own-dog-food" ... did you find stuff, that needs to be fixed while writing about best practices? Any war-stories to tell?

To be honest, we didn’t end up coming across too many issues with Arquillian by writing this book or GeekSeek; we’d waited until ARQ had reached a level of maturity before embarking on a large project to document its use in practice.  We did, however, encounter a series of known limitations, for instance the lack of Suite support, in writing.  Most of these issues haven’t yet been addressed because they’d require API changes in Arquillian which would break backwards-compatibility, and we have them on deck for a major version 2.0 when the time is right.

One bit I found particularly interesting is the idea of a Modular Test Suite. E.g. Module X adds Feature A to the app.  Now it’s possible Module Y is affected by these features on a test level. Why can’t Module X provide a Test Module to help Module Y? Security is a good example. Module Y doesn’t know about security, but if the Security Module is included, Module Y’s test suite starts to fail. Now if you want to explore the idea that a single test can run under multiple configurations (e.g. on a Module level and on an App level) like we do in the book, you would need some helpers to get around the new Security constraints. But what if the Security Module provided a Test Extension? In short, your own Modules provide Test Services / Management to the other modules.

Right, in many cases we found the warts inherent with Java EE or using Maven to manage the builds, and we tried our best to outline those and show some possible workarounds.

You're using all the latest and greatest. Including a REST/HATEOS driven backend for an AngularJS frontend. Do you believe that server side UI generation is dead?

No, server-side generation of the UI certainly has a place, as does client-side.  When you deal with dynamic elements only via JavaScript, this tends to give way to the common “loading” syndrome when the page is first rendered and then a series of async calls are made to pull in data.  On the other end of the spectrum, server-side generation can lead to a UI-only approach where services don’t need to be exposed in a RESTful fashion, and may in some cases be more resource-intensive than is necessary.  As with anything, we recommend that developers be aware of the strengths and limitations of each approach and choose solutions that best fit your requirements; sometimes a hybrid approach might be best.

In our case for GeekSeek, we’d simply felt that it was worth showing how to use the services of Java EE without necessarily using JSF for the view layer.  Having Angular tap into our RESTful interface to get at the backend data was a logical choice for us.

The book uses Java EE 6 as technology. And honestly I believe you did a great job. What do you think about Java EE generally and the improvements we got with EE 7 particularly. Wouldn't that have made your life easier?

It’s important that developers judge Java EE fairly; it’s aim is to standardize where appropriate and bring together a wide swath of disparate technologies.  It intentionally leaves choice to vendors in a number of areas, and by nature of being a standard cannot necessarily evolve as quickly as some may like, as that would cause too much instability inbetween major releases.  So it provides a very nice base upon which to build, and affords choice to the developer.

With that choice can come confusion, which is a large motivation for our book.  We look to illustrate a few ways of bringing the whole picture together.

Java EE 6 did have some limiting factors which we encountered and devised custom solutions to address.  For instance, JAX-RS 1.1 does not define interceptors, so we added a CDI-based interceptor chain to our REST layer.  And CDI 1.0 defines beans.xml metadata per archive with no global ordering or configuration, so we again added our own chain to address this.

WildFly was just certified as EE7-compliant during the book’s production process, and EAP will follow later, so we’ll look to provide updates to the application as time progresses; that’s why we’re releasing GeekSeek initially as an EE6 application.

You point your readers to JBDS and Forge for development. Honestly guys, which IDE are you using and why?

Aslak: Eclipse. For 15 years or so. I’m getting old, too many shortcuts built into my brain to change ;)

ALR: I use both standard Eclipse and the JBDS toolset, as well as IntelliJ IDEA Community.  It really depends upon what I’m doing; I love IDEA for most development and find it more resource-efficient, but I like m2e in Eclipse when I’m dealing with Maven dependency issues, and JBDS when doing anything with Forge or OpenShift because of the nice integration there.

The code runs on WildFly which isn't exactly a surprise. Do you test on other app-servers? Arquillian has a broad range of container adapters and I somehow expected to see some more here.

This again hits at the nature of Java EE; applications in compliance to the platform still need to run somewhere, and vendor differences start to show up when you put together a non-trivial application.  While porting between WildFly and EAP is generally a relatively-simple endeavor, there are still enough differences that running the exact same codebase on both targets requires some thought and intelligent implementation.  These gaps grow in orders of magnitude once you start to incorporate servers offered by other vendors, so for the sake of simplicity in delivering one source tree without forks to customize for individual application servers, we chose the community WildFly and free-for-development EAP (and its OpenShift cartridge) as runtimes.  We absolutely encourage our readers to port to their application server of choice and share their patches or experiences with us!

The book and source are licensed under Creative Commons. So, basically free to everybody and accessible on Why do you still do a printed version? What is the benefit of buying one? 

It’s really simple; we wanted the book to get into the hands of as many developers who might benefit from its lessons.  O’Reilly has a global reach and streamlined process to deliver to large online retailers and traditional brick-and-mortar stores, and they were open to our desire to deliver the text under an open-source license.  They additionally provide editorial and graphics work to really help deliver a more polished product than we’d have done on our own, so we decided to partner with them in the name of getting a higher-quality work out to as many people as possible.

I've always wondered how much work it actually is. Did you spend all your evenings on it? 

Aslak: I would say, roughly 2 months full time. The problem is when it’s not heads down full time, you lose so much built up contextual information along the way so it gets harder and harder the longer it goes between each write session.

ALR: Exactly; the work itself isn’t terrible in quantity, but when you couple it with a day job and have to deal with constant context-switching, it’s easy to let the book occupy more mental space than the actual time it takes to deliver would indicate.  It’s also not the kind of thing that you can do mindlessly; like software, writing requires a decent design phase and constant iterations to align your objectives with the code, and explain in a fashion that’s hopefully concise and complete.  It’s an exercise to our readers to judge how well we executed there. :)

Tuesday, January 28, 2014

WildFly 8 vs. GlassFish 4 - Which Application Server to Choose.

It's been a while since my last blog. I've obviously been busy with different things including my main job. After some more questions regarding the right choice for application servers cross my way it is the right time to pick this topic up again and share my thoughts.

One of the most read post on this blog is the post about which Java EE 6 application server to choose. I've been looking at a bunch of criteria and knocked down the different certified servers according to a very basic but common pattern. Given the main guideline that each server should be available as OSS and commercially supported variant the post concludes with recommending both GlassFish 3 and JBoss AS7 as valid choices. After the GlassFish roadmap updates from last November the situation seems to have changed and many people tend to accept that AS7/WildFly now remain the only alternative. Today I'd like to shift the focus on this a bit and try to put the discussion back into a more strategical context and elaborate further on the impact on the GlassFish vs. WildFly decision as of today.

Basic Strategy Principle for Java EE Applications
Beginning with having made the decision to develop a new application based on Java EE you already assumed a couple of things. Java EE is called an industry standard for a reason. It means it is widely adopted and still not officially captured by one of the official standards or standardization organisations like DIN/ISO or IEEE. The JCP provides rules and regulations for it and governs it along a broad contribution from different individuals and organizations. Calling it an open industry standard is common and valid for me. You may weight the difference between both on your own. In principle the Java EE certification list provides you with a range of different products which at least comply to the so called Java EE TCK. The TCK is heavily discussed and it is safe to assume that it does not cover every single line of all contained specifications completely. But every certified Java EE server should basically be ready to execute a Java EE application. The write once - run everywhere principle can be achieved (at least to a certain extend).
Bottom line of your decision is: Avoid (vendor) specific features and build your new application on an open industry standard which provides flexibility and choice between different products and vendors.
Beside this you gain additional value by having the flexibility to choose from a broad range of companies and developers offering skills and services in Java EE technologies.

WildFly 8 and GlassFish 4 are equal from a Java EE 7 Perspective
With the announcement of WildFly 8 CR1 it passes the Java EE 7 TCK. Even if the official paperwork obviously haven't been completely processed it looks like the 8 final will officially be certified. At least with regards to the Java EE 7 technologies both servers offer the same. There is and always has been different additional features surrounding the core technology stack but I haven't done a complete feature comparison of them and I honestly have no intend of doing it.
If you plan on doing a greenfield development come up with your own decision making process and weight those additional metrics in. You're already and Oracle or Red Hat customer? Or using additional infrastructural components which work best with the one or the other? In my experience you also need to weight in a couple of others (from my own experience we are talking about >=30) and rank them accordingly.

Migrate from GlassFish 2.x, 3.x to 4.0?
The most commonly asked question these days. What should I do with the applications which are already running on GlassFish 2.x or 3.x? It probably is the hardest one. I would need to know a bit more from you to answer it.

Oracle/GlassFish Customer/Shop and not changing anything?
Are you already using the Oracle GlassFish Server (commercially supported version) or are you using the Open Source version? Do you plan on extending the application or use newly introduced Java EE 7 features? If you are hooked up with Oracle or the commercial version already and you are NOT planning on making any changes you basically don't have to worry about migrating at all. Existing Oracle GlassFish Server 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy (PDF). I basically don't recommend to migrate at all if you're in that kind of setting. The extended support for both servers ends in January 2017 (GFv2) respectively March 2019 (GFv3).

Oracle/GlassFish Customer/Shop and willing to use new Java EE 7 features early?
So you are an Oracle Customer and you are keen to use latest technology early? Or you need to heavily modify your applications?
You basically have three options: Stick with the GlassFish 4 OSS Version (without support contract) or move to the WebLogic 12c (12.1.4) which will most likely have full EE 7 support or do this step by step by first moving to GF 4 and then to WebLogic 12.1.4 later.
Directly switching to GlassFish and planning to go on with WebLogic in production later carries the risk of using different application servers in development and production. You need to value this in and handle it accordingly.
To completely reduce the risk I would recommend to wait for at least the WebLogic 12.1.3 which is expected to have a first set of new Java EE 7 specifications and will hopefully available sometime during the first half of CY2014.
If you don't run a mission critical application and you don't need a support contract I recommend to migrate to GlassFish 4.0 in order to facilitate the already available infrastructure and skills and contracts. To me there is no point in hastily switching vendors. Be prepared for ending support contracts and plan on evaluating your decisions about the right Open Source Application Server then.

Not really and Oracle Customer/Shop, not changing anything no interest in new EE 7 features?
Don't migrate at all until your requirements change. You might start evaluating your next Java EE 7 server product soon. But as of today there aren't many certified alternatives available.

Not really and Oracle Customer/Shop, changing requirements, will to use new EE 7 features?
Might be time to revisit your IT landscape this year. It seems as if you've decided to go with GlassFish at some point. You might have to revisit your former decision and evaluate what to do. To make a well grounded decision about your next Java EE server you are too early. The certification matrix for EE 7 servers is mostly empty. Wait for more alternatives to come up. I expect this to take most of CY2014.
If you have the need for new EE 7 features as of today and you need to be able to buy commercial support in the future but don't need it right here and now the only alternative you have is WildFly 8.

What does the future hold for GlassFish 4?
I wish I could tell you. I guess I made my points in the earlier posting. Oracle needs GlassFish to stick around as Java EE Reference Implementation and given the number of commonly used components in both WebLogic and GlassFish it will always be there. And it is safe to assume that the Java EE specifications will always be the latest and greatest in GlassFish. But the Java EE ecosystem lead to a bunch of vendor specific extensions and features which are not really covered by any specification. Those are commodity  to all of us (mostly clustering, admin Features, embedded server) and we don't want to miss them in many cases. Further on the patch frequency and grade of community participation will be crucial factors for the successful spread of GlassFish among projects and developers.