Is Oracle Doing what Sun Couldn't? I Can't Bring Myself To Think So.

I'm staring at my mug with the image James Gosling created - Tux standing in front of Sun's gravestone, consoling Duke's loss. Sun left us too early... it was always an amazing playground of tech, giving us cool stuff like Jini and JMX. I was ill at ease with Oracle before their acquisition of Sun, and now I'm even more so.

Still... I noticed that Oracle recently has done something that Sun hasn't been able to do. While Sun tried to govern Java with some sort of loose democracy known as the Java Community Process, it never was able to get consensus with the group and move forward. Perhaps Oracle's benevolent dictatorship is what the JCP needed - for now they have been able to get IBM to join forces with them and work on development of the OpenJDK.

This is a pretty big deal, as Gosling notes. Not only does this collaboration accelerate open Java development but this also possibly reduces fragmentation since IBM will be scaling down their work on the Apache Harmony JVM. RedHat's IcedTea implementation is already married to the OpenJDK codebase, and without IBM's backing of Harmony the OpenJDK implementation quickly becomes a de facto standard.

If Oracle can light a fire under the JCP and put significant engineering efforts around an Open Java development tookit... I dunno. Maybe things will turn out all right after all. I'm still pretty hesitant.

Eclipsed by a Bean Maven

I've long been a fan of NetBeans, but for the past several years I have had to use Eclipse. Nearly all of the projects or organizations I've walked into have had pre-existing standards and ways of doin' stuff, and the worst thing you can do as a greenhorn in a company is try to switch horses mid-stream.

Wow... I get a triple combo score for clichés there.

Now I get to bootstrap a development team and decide what we use. The awesome thing is that there are now something like elebenty kabillion IDEs, RIA frameworks and rapid application environments. JSF no longer blows. Everyone uses the same build files now. XML hell is now in the rear-view mirror. Vendor lock-in isn't what it used to be thankfully enough.

When I started building out projects I went for an IDE with tight Maven 2 integration, JSF 2.0 support, Java EE 6 interwoven and nice Subversion tools. I imagined that I'd be heavily leveraging plugins from the Spring IDE project and plugins from JBoss, notably the Drools Workbench. All this plugin support caused me to initially lean towards Eclipse.

As I went further along I also started using GlassFish v3 instead of Tomcat, exploring JavaFX and increasingly using Maven 2 for continuous integration and artifact generation. I didn't really use the features of Spring IDE at all, and while I did use the Drools Workbench I ended up doing more decision-table type stuff, making drl's easier to manage. Ultimately a deciding moment came when I needed to do a very quick-and-dirty desktop application with a simple user interface... something that just needed a logo, URL text field, username and password. For the life of me I couldn't find any free/OSS plugins for Eclipse that let me create a quick JDesktop or Swing application... at least within the 45 minutes that I had available. After pulling out my hair I had a sudden flashback to the good ole' ConsultComm days and reminisced "boy, creating UIs in NetBeans sure was swell." It was at that point when I tried to think of any reasons why I was sticking with Eclilpse... and came up empty.

I've switched to NetBeans, which the IDE itself made extremely easy with it's Eclipse workspace synchronization. Read that line again... synchronization. I know! Mind blowing! It doesn't import the project, it allows your project to remain in the Eclipse workspace while also being mantained in NetBeans. Easy!

All the UI goodness I remembered was still there. In no time flat I had created the entire UI and help menus. Not once did I consult a HowTo or documentation, instead it all immediately made sense. The entire project was done before lunch.

I have shifted all of my development to NetBeans now, despite the fact that I can't be sure where its future lies. I don't care. I'll take advantage of an easy-to-use IDE as long as I possibly can. If I switch back to Eclipse in the future it will like be because I was forced to... just like every other time in the past.

As for standardizing on a development environment: I've learned that no one IDE fits all. Every developer has a preference, and with Maven 2 reaching near-ubiquity it doesn't matter nearly as much as it used to. I say let every developer chose his or her IDE, just pick the one you work most rapidly and naturally within. As long as I can build it with mvn on the command line I just don't care.

Java EE 6 - Gee, 6?

Java Enterprise Edition 6 was just released, even with Oracle's possible acquisition of Sun looming on the horizon. In the past I've seen J2EE and Java 5 EE releases come and go whilst I went on not caring. It wasn't because I didn't need anything more than Java's Standard Edition... I do... but the Java Enterprise Edition releases always seemed to be released with features I needed nine months ago and found in other frameworks.

I decided to take more of a look within this release and give it a fair shake. This release had a lot of nice stuff but was still playing catch-up with other tech: JPA starts catching up with the functionality offered by Hibernate, JAX-RS (RESTful Web Services) is finally produced as an answer to the myriad of other REST frameworks and dependency injection finally gets introduced into Java proper. All of these additions are features that were already offered by alternate libraries over a year ago (some of them more than five years ago) and are just now becoming standard.

Inversion of Control isn't the only elder pattern that finally debuts in Java EE 6. Asynchronous responses appear throughout the new Enterprise Edition, finally allowing threads to stop blocking subsequent operations. Asynchronous processing is finally available in the Servlet 3.0 spec so inbound HTTP requests don't have to hang forever while they await all the info to formulate a response. Session Beans can now be invoked asynchronously so EJB execution doesn't consume a client thread and eat up threadpools. JSF now has AJAX support for asynchronous webapp calls. REST-based Web Services allow for Web Service exposure with much less resource utilization and much higher concurrency through more streamlined asynchronous HTTP calls. All of these features not only have been present in alternate libraries for some time, but entire protologisms and design patterns have been honed to allow for just such asynchronicity. Comet and callback methods have been a predominant pattern for some time now, although Servlet 3.0 is the first time a Java Enterprise Edition has allowed for asynchronous Servlet processing. Now that WebSockets are becoming more prevalent Java Servlets are going to need to catch up to everyone else yet again and in short order.

Am I even tempted by this release of Java Enterprise Edition? Maybe kinda. I like annotation-based models, as I've seen how deep XML hell truly goes. JAX-RS annotations are a compelling alternative to JAX-RPC, and the new Bean Validation annotations would likely be very helpful. Asynchronous EJB invocation, along with a more minimalistic and annotation-based EJB spec, may even convince me to finally give Enterprise Java Beans a try once more.

I already use JPA, JAXB, JMS, JMX, JAAS, JAX-RPC, JavaSpaces and Servlets/JSPs/JSTL but in more of an a la carte sorta mechanism, intermingled with Spring, DWR, Hibernate and Camel. Now that I've typed the previous line... I realize that even though I've never intentionally downloaded the Java 5 EE package from Sun it seems I've been using Java Enterprise Edition all along. Weird. I guess it has slowly seeped into the crevasses of my frameworks, unintentionally filling out the rest of the libraries I use. Now that we have REST support and asynchronous context... I might walk the final yard and intentionally download it this time.