JavaSE 7 review - a missed opportunity

JavaSE 7 fails to address the problems with JavaSE 6 and the challenge of creating an open platform for enterprise developers and organisations to innovate around. The single biggest challenge originally facing JavaSE 7, Modularization, has been de-scoped by the Sun/Oracle Java leadership despite having 5 years to deliver it. Feature complete? No very much incomplete for what it needs to be and a missed opportunity for Oracle and the Java community. Its sad to see such a poor improvement having such a detrimental impact on what was once the most vibrant, friendly and huge development community on earth.

So JavaSE 7 has been "approved" by the JCP even though its not actually been through a proper JCP process so the specification has actually been defined by the OpenJDK development team... So is JavaSE 7 any better from an enterprise or agile/lightweight development perspective than the Joe Sixpack focused JavaSE 6? Which wasn't IMO focused on these core Java markets at all.

So what is in JavaSE 7?... well from the OpenJDK website

vm	JSR 292: Support for dynamically-typed languages (InvokeDynamic)
	Strict class-file checking [NEW]
lang	JSR 334: Small language enhancements (Project Coin)
core	Upgrade class-loader architecture
	Method to close a URLClassLoader
	Concurrency and collections updates (jsr166y)
i18n	Unicode 6.0
	Locale enhancement
	Separate user locale and user-interface locale
ionet	JSR 203: More new I/O APIs for the Java platform (NIO.2)
	NIO.2 filesystem provider for zip/jar archives
	SCTP (Stream Control Transmission Protocol)
	SDP (Sockets Direct Protocol)
	Use the Windows Vista IPv6 stack
	TLS 1.2
sec	Elliptic-curve cryptography (ECC)
jdbc	JDBC 4.1
client	XRender pipeline for Java 2D
	Create new platform APIs for 6u10 graphics features
	Nimbus look-and-feel for Swing
	Swing JLayer component
web	Update the XML stack
mgmt	Enhanced JMX Agent and MBeans [NEW]

So lets go through these from the perspective of what most people do with Java, namely the delivery of enterprise quality applications which are primarily delivered on servers, more and more in a virtualised environment. So yes JEE is more for those folks than SE but lots of smart folks deliver Server side apps, or desktop agents, which aren't about delivering a Swing GUI. They might use the eclipse approach if they are doing desktop for instance. The point is that these folks, who are the vast majority of Java's developer base, are folks who choose their frameworks and libraries for their specific problem. So how does this new feature set help us?

1. Non-dynamic languages - irrelevant for Java folks, but it makes sense in the VM, might even support some clever language changes in the future but its not for the Java folks so sets say - Negligible improvement
2. Strict class file checking - Okay needed and part of the specs - Minor improvement
3. Small language enhancements - as it says on the tin, minor but nice stuff - Minor improvement
4. Class loader stuff - needed but again its minor - Minor improvement
5. Concurrency and Collections stuff - okay I'm biased here but if Doug says we need it, we need it. Actually things like the Hashmap are great additions and with the rise of multi-core this is important stuff - Improvement but not a full "point" release
6. Internationalization - Required but again - Minor improvement
7. IO improvements - Good stuff and for certain applications great to have, impact wise its the same as Concurrency - Improvement but not a full "point" release
8. Cryto - now for me we are into the world of "its a library" so yes its good that we can all use ECC crypto... ummm but how many people actually do? Would a dynamic class loader via URL or a build compliance piece not be better? - Developer decision, bloat risk
9. Client - All of this is a waste of time for enterprise developers, great I've got a new 2D render pipeline, that really helps the performance of my server side app and just kicks ass with the extra weight this adds to provisioning a VM. - Desktop
10. Web - how miss named is this one? Its actually XML and again this is the sort of thing that would be much better left to developers and deployments. We've seen before that having JAX-WS hard-coded in JavaSE was a dumb idea and this applies generally to the XML pieces. Lets be clear here, people choose their own XML encoders and approaches on a regular basis, having a standard Java library for these things and at the JavaEE level enforcing these as standards makes sense. It does NOT make sense for these to be part of the JavaSE platform as people who don't want to use JavaEE are liable to either not want to do WS or are using a framework that bundles a later version or uses different XML libraries. - Pointless upgrade to bloat
11. Management upgrade - I like MBeans, I've written lots of fun stuff with MBeans that made Tivoli users smart but did I care whether it was in JavaSE or not? No I did not. If I'm deploying JMX to manage my Java App I'd like to bundle it in the deployment. It even says that if you were a JRockit user you already had this stuff - Library upgrade

So what have the Sun, now Oracle, team given us for these 5 years of work for their whole team in a world where they got to set the agenda? Well I'm going to drop out the Doug Lea stuff as that is Doug Lea FFS and he has quite the JCP. So what are we left with that as an enterprise developer of Java we look forward to? A few patches to Class loaders, VM, Internationalisation and the language. A bit of improvement for those doing file and socket handling at the lowest levels. The rest? Basically libraries that we are already either using (e.g. Crypto) or really wish weren't in there at all (JAX-WS).

And what about the sort of things I thought would be good in JavaSE 7? Well a quick look at the deferred stuff speaks volumes...

• JSR 294: Language and VM support for modular programming
• JSR 308: Annotations on Java types
• JSR TBD: Project Lambda
• Modularization (Project Jigsaw)

These were the things that were talked about for JavaSE 7 over 5 years ago. A fully funded, fully fledged team has been working on these elements for over 5 years and has deferred them until the next release. Modularization in particular was discussed during JavaSE 6 but was felt to be too aggressive in that release. Its rather hard to believe when we look at the rise of languages like Erlang, support pieces like Hudson and the creation of entire new business models that a well understood task like Modularization (something that people have been doing beyond the SE platform for years (Ivy, Maven) and inside it with Java Web Start) is such a mammoth task. To put it in context, J2SE 1.4 (assert, regular expressions, exception chaining, IPv6) to Java SE 5 (generics, annotations, auto-boxing, vaargs, concurrency utils) was 2.5 years, 5 to 6 was 2 years.

So is JavaSE 7 a great leap forwards that addresses the enterprise challenges of Java and leaves developers able to innovate and drive the industry forwards?

Well we all know the answer to that. No it isn't. The posting of this spec on the "Open"JDK site is also rather telling, the message appears clear to Apache and others that "innovation" is that defined and constrained within a very small and very slow moving mindset, one that is less driven by the industry and enterprise demands and more by local Silicon Valley views on what might be cool.

If JavaSE 7 was tagged as JavaSE 6.5 it might be a bit more accurate but it looks like we will have to wait until JavaSE 8 (late 2012) before the things that should have been done back in 2006 are done. The original JSRs behind this kicked off in 2004/5.

I can't think of something that better highlights the problems with the current approach to the evolution of Java than modularisation. In 2005 everyone knew it was a problem, in 2006 it was pushed from JavaSE as it wasn't quite formalised and thanks to the mentality, management and approach of the Java platform we'll be lucky if its ready 7 years later and very lucky if the solution is widely applauded, being clear this was the ONE big thing that the Java team had to do and it was originally scheduled for JavaSE 7.

Conclusion: Java has lost 5 years of innovation and needs a significant kick up the arse to change its direction and pace of innovation.

A key part of this comes down to how Apache are treated and how much control is released in order to drive the market size, which will benefit Oracle who can commercialise way better than Sun. As Bill Joy used to say "The smartest people don't all work at Sun" and the shift of smart people away from Java as it has stagnated is the biggest single issue facing the platform today. Something needs to change

Technorati Tags: SOA, Service Architecture