Without a doubt, the release of mustang is over shadowed by Java being open sourced. We've talked about -- and still talk about -- the open sourcing of Java at length, so I won't get into that here except for a brief note.
Aside from a governance model for OpenJDK, I'm eagerly awaiting the addition of some open source developers to the JCP. My enthusiasm is tempered by the reality of "things taking time," but that's the next thing I'm on the look out for in Java-land. Along those lines, I need to check-up on the currently being worked on rev of the JCP process. Heather VanCura was nice enough to brief me over coffee at ApacheCon this year and now it's worth a deeper dive.
Release Notes
So, back to Java SE 6.0. As my dev friends often ask me about any topic, "why should I care?" I'll tell you right away that 6.0 is not as exciting as 5.0: there are no language changes. Adding in enums, generics, varargs, the for loop, auto-boxing, and annotations was a big deal and deservedly generated a lot of interest in 5.0.
While 6.0 has many interesting features that are of long-term equal importance -- esp. scripting -- it's not going to get you all hot and bothered like 5.0 did. (Oooo! varargs!) I've been hard pressed to find a Java developer (out of the 10 or so I pinged) who's chomping at the bit to get this release.
All this doesn't mean you should ignore this release: that'd just be silly. There's plenty of interesting things:
Performance
Every release of the VM increases the VM's performance and, of course, fixes bugs. It's worth upgrading your Java version if only for those performance gains. I've been in several discussions over the years about putting time in the schedule to upgrade Java.
While there's always the risks of introducing new bugs and wasting developer and QA time upgrading their own setups to a new version, my default assumption is to upgrade to newer versions of a core platform as they become available. For something like Java where you don't have to re-code for API or functionality change, it's even less risky than something like Struts or Maven that might change more dramatically.
Theoretically, with Java, you just add in the new JDK and JRE and without much hassle get the performance increase and bug fixes for free.
Debugging
As someone who's spent days tracking down Java errors both in lab and in the field, anything to help with debugging a running Java application is much welcome. As this article by Mandy Chung covers in-depth, 6.0 ads many new ways to trouble shoot a Java app, esp. in the area of memory leak hunting.
Part of this is instrumenting the VM better. "Instrumenting" means adding more metrics to the VM that third parties can monitor. Systems management wonks like myself get all tingly at the idea of adding more metrics to anything. Aside from weirdos like that, it's good for trouble shooting applications on the cheap without buying and configuring third party tools like AppVision, Wiley, or Identify.
Bundling jhat for heap analysis is great. Hopefully adding in jhat and related tools to Java means jhat and related tools will scale better than their "experimental" versions have in the past.
As small thing to be excited about, OutOfMemory exceptions will now have stack traces. Sure, who knows if the place you actually got the exception is where the leak is, but at least it's something more than the tight-lipped OutOfMemory we've had in the past.
Web Services
While I'm not a huge WS-* fan, I know that bundling JAX-WS in SE will make fans and unwilling fans lives a little easier. SE 6.0 on it's own can server as both a web services client and server (of course, it's best to add in a more robust server for production) that should make "playing around" with web services easier than having to download that stack separately.
The larger point here is deceptively subtle: part of the "goodness" ruby, python, and other dynamic language stacks are that they come with so many libraries and APIs built into them rather than as add ons. Ruby comes with an RSS library for example. Adding in libraries, like web services, that Java developers increasingly use "all the time" makes the developer's lives easier.
JSR 223: Scripting
The most exciting addition in SE 6.0 is the implementation of JSR 223, or "scripting." If you've listened to me talk about Java for more than 5 minutes, you know that I see becoming a platform for multiple languages as key to Java's future.
The Java language is beginning to show it's age and, more importantly, I think the development world has had a mono-lingual mindset for too long. Increasingly, a platform that supports best of breed approaches to development -- like LAMP mixed with JavaScript for UI and Java for "enterprisey" processing -- helps developers and companies deliver innovative products fast enough to stay afloat.
The addition of JSR 223 to Java doesn't accomplish all of this. Rather, it lays the foundation to make it possible. I'll be watching how the community takes to the scripting API and how Sun and others help encourage making Java truly "talk in tongues.". If you follow my other podcast, you know that I'm already trying to get people moving on this front.
Others
As always, there are numerous other additions. The JDBC 4.0 and SQL via annotations features are particularly interesting to me. As I said back when beta 2 came out, bundling Java DB with the JDK is nice.
There's much to do about the desktop/GUI improvements; I'm more of a server side person, but if you were into Swing/AWT, I can see that access to native services -- like the system tray and web browser -- would be exciting. In the zero-sum mind-set, the open question here is how much help those additions will be in the face of Eclipse RCP, AJAX, Apollo, and every other UI framework that's stolen the collective gaze from Java GUIs.
.Net
As I side note, along with the idea of speaking tongues, taking into account the ongoing module/component work, you might be thinking: this is starting to sound like the CLR and Assemblies, that is, .Net, and how 'bout them annotations?
Indeed! Let's hope Java steals...uh..."gets inspiration from" the way properties are handled in C# and dynamic languages as well. As I said to one reporter last week:
fixing the way properties are done on objects is long overdue: the JavaBean idioms have been a great help for years, but developers are increasingly looking for a better properties system.
I'm not much for the, pardon the phrase, pissing match between Java and .Net. I'd rather see each language and ecosystem pull the best from each and keep truckin' along.
A More Open Platform
My overall sense is that SE 6.0 is opening up the Java platform technologically. "Small" things like access to the complier, better annotations processing, and "large" things like adding in scripting support are helping make Java into more than just Java.
I've made the somewhat controversial statement in the past that Java developers can be technologically myopic. Slowly, I've been seeing this trend change -- with things like Zimbra that mix languages and platforms (Linux/web browser) -- and SE 6.0 should give the underpinnings to help Java developers become developers...who happen to run on the Java platform.
Disclaimer: as mentioned above, I've consulted about this announcement. Not to mention that Sun is a client and I was a Java developer for many years. Eclipse is also a client, as is BMC.
Previous Topic
