Thursday, December 11, 2008

Java 7 Update from Mark Reinhold at Devoxx

This is a summary of Mark Reinhold's Java 7 update given at Devoxx, with a few comments from myself. Mark described his presentation as a provisional plan and not binding.

The changes in Java 7 will come from Sun and others.

Among the "Big" changes from Sun (with what looks like a prioritized ordering):

  • Modularization - 294 and project Jigsaw
  • 292 - JVM Support for dynamic languages
  • JSR 203 - More New I/O APIs which are nearly finished, includes true asynchronous I/O (not just non blocking I/O) and finally a real file system API
  • JSR TBD: Small language changes (following)
  • Safe rethrow - Allows a broad catch clause, with the compiler being smarter on what you're allowed to rethrow based on what is thrown from the try block. (I had not seen this before but it looks nice)
  • Null dereference expressions - Null checks with '?' syntax similar to Groovy... lettign developers avoid a nest of null checks.
  • Better type inference - Example around generics instantiations, but it was not clear how far the inference would be taken (the more the better in my opinion).
  • Multi-catch - (yes!) allows a comma seperated list of disjunctive exception types in catch clause.
  • Joe Darcy is leading effort in Open JDK and his blog was referenced:
  • JSR 296 - Swing application framework - It still needs to be easier to create Swing apps.
  • A forward port of 6u10 features (Java Kernal, QUickstarter, New Plug-in, etc.)
The "Small" Sun changes are:
  • SCTP (Stream Control Transmission Protocol) - Driven by big customers, probably proprietary
  • SDP (Sockets Direct Protocol) - Again, customer driven
  • Upgrade class loader architecture - Work started in Java 5 and continues to evolve. There are some deadlock issues today in classloader delegation that will be addressed.
  • Method to close a URLClassLoader - seems simple but actually tricky to implement.
  • Unicode 5.0 support - "just got to do it"
  • XRender pipeline for Java 2D - This was an Open JDK Integrators Challenge project,and is an analog to the OpenGL pipeline but much more portable across x11.
  • Swing Updates - JXLayer, DatePicker, CSS styling (maybe) that Ethan Nicholaus (sp?) has been working on
The "Fast" changes from Sun (apparently, this means performance improvements):
Hotspot run-time compiler enhancements
  • G1 Garbage collector (available in 6 experimentally soon) - Leads to much smaller pause times and hopes to replace CMS (Concurrent mark sweep) GC
  • Compressed pointer 64 bit VM
  • MVM-lite maybe - Multiple Virtual Machines will help you run isolated applications and allow a kill -9 on a Java application. Mark said it is not clear what problem would be solved, and original project was extremely ambitious, but desire to drag apps out of browser plugin presents a good usage and need for MVM.

Other's Features:
  • JSR 308 - Annotations on Java Types - Driven by Prof. Michael Ernst and Mahmood Ali. Encode more compile time assertions in code (like the @NotNull annotation), which is checked by the static checker. (yes!)
  • Concurrency and Collections Updated (JSR 166 continues). All the features announced on the concurrency interest mailing list by Doug Lea yesterday: Fork/Join, Phasers, LinkedTransferQueue, ConcurrentReferenceHashMap, and Fences
The featues not in 7 (some of them, anyway the list is actually infinite)
  • Closures - No consensus around single proposal
  • Reified generics
  • 1st class properties
  • Operator overloading
  • BigDecimal syntax
  • JSR 295 - Beans Binding
And finally the big news... a release date! "Java 7 in Early 2010" - Mark Reinhold


Unknown said...

Thanks for this post. Clears some of the mist.

I am glad to see that invokedynamic and modularization are top priority. I think the importance of these two cannot be overestimated.

Did they say anything about a release date?

Hamlet D'Arcy said...

"Java 7 in early 2010" - Mark Reinhold

Jacek Furmankiewicz said...

If you guys included MigLayout (the highest voted Swing RFE right now) you would move Swing layout management 2 generations forward ahead of any other language.

And the code is all done for you. Just refactor the package names.

MigLayout makes all other Swing layout managers look like a toy. I've had people's jaw drop when I gave them MigLayout training at work.

Paul Hammant said...

No Parameter name access?

Mark Reinhold said it would be considered by the Java7 team.

See http://paranamer.codehaus,org for an interim solution.

Unknown said...

I'll second the support for MigLayout! Also, my understanding was that the SwingApp Framework had been put on hold as the guy working on it had left Sun...

Biggest question - what about the new Date/Calendar api based on Joda??

Alex Miller said...

No thumbs up or down on JSR 310?

John Stracke said...

SCTP is not proprietary; it's an IETF standard (RFC-4960). It's like TCP, but with message boundaries.

Hamlet D'Arcy said...

The datetime JSR (310) was not mentioned. But I just asked Stephen Colbourne about it and he said it was mostly a lack of time. It's an open project, perhaps it is time to shut down the browser and start helping with the latest date time code, eh? ;)

Alex Miller said...

Sounds like a good idea. Let's pull it over the line!

Harold Fowler said...

I agree, no doubt a good idea. hit it!


Wim Bervoets said...

Thanks for making this nice overview!

Matt said...
This comment has been removed by the author.
Matt said...

If reified generics won't make it into Java 7 the language, I would still really like it to make it into the Java 7 VM so that other languages can take advantage of it. Why stifle all languages on the JVM just because we don't want to break backwards compatibility in ONE of the platform's supported languages?

I think it's time to evolve Java the language and Java the platform separately. Invoke Dynamic and VM performance improvements should be in a JVM JSR and Java language enhancements in a different JSR.

Hamlet D'Arcy said...

@Matt - I'm no expert, but couldn't a language on top of the JVM do this today by taking the same approach to templates the C++ did? In my understanding, a generic class was a template, and instantiations of the template were new, synthesized classes to the type system. For instance Foo<T> was a template, and Foo<Integer> was an actual class that was synthesized by the compiler. Perhaps a bytecode compiler for a new language could treat parameterized classes this way so that the JVM is unaware of what's going on.

Unknown said...


The approach you are describing does not interact smoothly with the reflection system: A .getClass() call will return the base type (that is List rather than List<String>).

A language can workaround this limitation by implementing its own reflection mechanism by augmenting Java's reflection with reification. This has the following issues:

First, There is no standard for this extension so interoperability between languages will be difficult. Second, instanceof (possibly in existing libraries) will be unaware of reification.
Finally, JVM-issued type checks (arrays, signature compatibility in verification) rely on instanceof, so valid code may be rejected.

Matt said...

@Hamlet - you may be correct, I'm no JVM expert either ;) I may have made a false assumption because I don't know of any languages on the JVM that support reified generics. But perhaps this is because they all want to be compatible with existing Java libraries. I found a blog post by Neal Gafter explaining the options available for introducing reified generics in Java, but he doesn't really provide what JVM changes would be required (although he says they would be necessary for at least one of the options).

However, I do know that C# compiles generic types at runtime using a JIT compiler. However, perhaps this is not the approach a Java implementation would take.

Anonymous said...
This comment has been removed by a blog administrator.
stephan said...

The Devoxx keynote from Mark Reinhold is now available on !

Unknown said...
This comment has been removed by a blog administrator.
木須炒餅Jerry said...
This comment has been removed by a blog administrator.