Java 7 SE approved... Meh

Hey Java SE 7 has been approved... now that is spectacularly quickly. You'd almost think that the normal Java Community Process had been ignored and instead the spec lead had taken an externally created spec straight to approval...

What is most depressing in reading the various Oracle (mainly ex-Sun employee) releases on this is that not a single one actually commented on the fact that of the people doing the approvals six of them expressed reservations about the licensing terms and the transparency of the process. All stated that they were approving it to get Java moving again and that there are issues they want to see addressed. I've said before that Java SE 7 is a nothing release for Java but its the approach and process that concerns me most. While I don't think the Java SE 6 approach taken by the Sun leads at the time was at all positive or constructive and the end result was not what was required at least there was a decent representation and debate. 18 companies spent 18 months and while the dumbest decisions remained (JAX-WS in JavaSE 6... how stupid does that look now?) at least there was a measure of debate.

The expert group for Java SE 7 was a sham, Five companies, five months and the first draft published days after the expert group was finally formed. The comments on the 'six companies who approved (+ Google who voted against) clearly indicate that there are significant changes required for Java to regain its position as the go-to platform for developers, enterprises and vendors.

I really hope that Java SE 8 actually does the radical things that the platform needs given the big shifts in the last 5 years since a decent release which didn't just dump cruft into the platform. Unfortunately I'm still concerned that the mentality is more to continue outside with a closed community which pretends to be open while actually pushing an already proven to fail line.

Java SE 7... I give it a 'Meh'.

Technorati Tags: SOA, Service Architecture

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

Have Adobe done what Sun wouldn't?

Sitting here at AdobeMAX I can't help but think that Adobe have created exactly what a bunch of people, including myself, have been campaigning for in the Java space for a while. Namely a lightweight profile that concentrates on the desktop area.

I've said before about profiles being an important direction for Java and to my mind that exactly what Adobe are doing with Flex and AIR. They've created a restricted profile based on a limited (but therefore powerful) set of functionality. What they don't have is a consistent model that works on the server (they use Java for that) but they have clearly defined a profile that works.

The point here is that the "kitchen sink" mentality pushed by the core Java SE team has clearly retarded the ability of companies to innovate and deliver different approaches for different environments. We are seeing this in part in the mobile space where Apple, Google and others (including Adobe) are moving away from J2ME towards more specific approaches which are often around taking desktop technologies and shifting them onto the powerful smartphone platform. With Java SE 6 being so large this just wasn't an option in the Java space (SavaJE have done some work, but who wants all that stuff on a mobile phone? MIDI support?

So while companies like Adobe are demonstrating, as are Microsoft with Silverlight, that new models work we are seeing Java turn into an ever bigger beast. This is really sad as many of the things here at Max are stuff I've seen demo'ed in Java many, many, years ago. The problem therefore is not that Java can't do this stuff but that the trajectory that Java has been on has prevented it.

So can Java get back into the lead? Potentially, but it requires a fundamental reassessment of how Sun view Java, both its core and the profiles and models that are acceptable. With the JCP appearing to be abandoned for Java SE 7 the omens are not great, but you never know. Until then it means we have to all start working in a mixed technology environment which is a pain in the arse, but it just isn't sensible to insist people download a web-server to run your client application.

Technorati Tags: SOA, Service Architecture