“My God, It’s Full of JSRs!”

That’s right, with apologies to 2001 (and a tip o’ the hat to Scott Bale for the title), we finally have a JSR proposal for Java 7 (JSR 336), and egads one for Java 8 (JSR 337) to boot.

This seems like an opportune moment for me to reminisce briefly about ye olde Java 7. Back in January of 2007 JDK 6 was fresh out of the gate and in an idle moment I did some poking around for clues about what might be in store for the next version. Surprisingly I found clues but no coherent source for information. I started piecing scraps together on my Java 7 page and doing a weekly roundup of news and links. Even back then, the BGGA proposal for closures was out, modularity JSRs existed, and while there were lots of ideas it seemed hopeful that an umbrella JSR would coalesce out of the noise in short order. I eventually abandoned the weekly roundups and started my Java 7 link blog, which I still maintain at a reduced frequency.

In the meantime, there have been numerous spec lead changes, the ongoing Apache Harmony TCK kerfuffle, the Sun acquisition by Oracle, 4 JavaOnes, and more closure/lambda proposals than I can count. So, here we are at long last.

The latest JSR 166y update is not included in the list above or in any of the other new JSRs, but I have no fear that the expected updates will be included as well.

All in all, I think having a JSR that includes the new filesystem API and the syntax sugar in the language changes will be good to have out there. In particular, I expect the diamond syntax, ARM blocks, and exception improvements to clean up some of cruft in common Java code today. And the JSR 292 invokedynamic changes are crucial to support the growing ecosystems of the leading JVM languages (like Groovy, Scala, Clojure, and JRuby). There are also a ton of improvements that have been bleeding into the OpenJDK 6 impl for years now, including major stuff like the G1 garbage collector, the quickstart improvements, etc.

And the following list of JSRs are called out as NOT part of Java 7 and are also NOT included in the Java 8 JSR so are presumably less likely to make it in Java 8 or maybe ever:

JSR 260: Javadoc Tag Technology Update – this has been pushed through at least 2, maybe 3 or 4 SE versions now, so no big surprise here. Custom doclets have allowed people to get what they need here anyways.

JSR 295: Beans Binding – originally part of JDK 7, 295 has been pushed out and may resurface in Java EE or SE in the future.

JSR 296: Swing Application Framework – 296 was hot early on but suffered personnel changes and never really re-gained any momentum. I think all the momentum in JavaFX overshadowed any interest in 296.

JSR 305: Annotations for Software Defect Detection – this is indirectly related to JSR 308 and doesn’t really need to be part of the JDK to be useful (it would just help standardize the annotations). It exists now and I suspect it will be around regardless of JDK inclusion.

Stephen Colebourne does his usual tasty analysis of the legal and political issues around licensing. I have the same expectations as him – these JSRs will be approved by the executive committee and per their ultimatum, I expect Apache to withdraw from the JCP. With the announcements from IBM and Apple re OpenJDK, it appears that Oracle has forged a path through this issue for better or worse and likely unstuck the JCP. This is very sad but I suspect the world will get on regardless.

I don’t expect Harmony to be getting much love from anyone but Google soon. It will be very interesting to see where the Google / Oracle lawsuit goes. Perhaps it will result in an OpenJDK deal with some money on the table (presumably Oracle is seeking financial benefits in the mobile market) or the schism could deepen and Google could take a deeper stake in Harmony as a custom implementation for Android.

The proposed schedule has a final release for Java SE 7 in July 2011 and for Java SE 8 in October 2012. I actually believe that Oracle will follow this release schedule. They’re making a public commitment here and while they may need to de-scope a bit to make it, I’m sure they will. Having a reliable schedule and plan will be a refreshing change even if we don’t like every decision.

Posted by Alex on Wednesday, November 17, 2010 at 12:06 am Filed under Java, jdk7 · Tagged with

Oracle may be suing Google over Android, but that I think is dust in the eyes of the Java community. First, Oracle’s core business is not in mobile. Second, the fast moving smartphone market does not have time to wait for the next underpowered MIDP version. It is a lost market for Oracle and I think they know that very well.

The real danger for Oracle comes from the cloud computing sector. It is also a growth opportunity they will try to explore in the future. I think that companies from that part of the market should be most concerned. If Oracle manages to impose its totalitarian control over the JVM, it will gain advantage similar to the one Microsoft has by controlling Windows. It will enable Oracle to offer better optimized products at prices that will be hard to compete with, because for the competition to offer a similar product, they’ll have to pay arbitrary JVM licenses to Oracle.

We can only hope that Google will decide to fight Oracle till the end and invalidate their JVM patents, but this is very unlikely to happen. More likely is that Oracle and Google will partner in their cloud offers.

I think you’re off your rocker if you don’t think Oracle is interested in mobile, which is experiencing tremendous growth and has a ton of potential. They may not (yet) have a horse in the race, but you can bet your Java license they’d like to extract a hoof per horse, if you know what I mean.

I also have to believe that Oracle sees the cloud as a place to sell a ton of new licenses, whether they are MySQL or Oracle Coherence or professional-grade JVMs or whatever other technology Oracle can shove into the enterprise.