Hamlet D'Arcy has been writing software for over a decade, and has spent considerable time coding in C++, Java, and Groovy. He's passionate about learning new languages and different ways to think about problems, and recently he's been discovering the joys of both F# and Scheme. He's an active member of the Groovy Users of Minnesota and the Object Technology User Group, is a committer on the Groovy project, and is a contributor on a few open source projects (including JConch and the IDEA Groovy Plugin). He blogs regularly at http://hamletdarcy.blogspot.com and can be found on Twitter as HamletDRC (http://twitter.com/hamletdrc). Hamlet is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Java 7 Update from Mark Reinhold at Devoxx

12.12.2008
| 17352 views |
  • submit to reddit

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: http://blogs.sun.com/darcy
  • 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

From http://hamletdarcy.blogspot.com

Published at DZone with permission of Hamlet D'Arcy, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Richard Osbaldeston replied on Wed, 2008/12/17 - 12:35pm in response to: Osvaldo Doederlein

Now, JavaFX's GUIs will typically be much more sophisticated with all sorts of effects, media, etc. and in a future release (2.0?)

But JavaFX is for all devices isn't it? how many mobiles will have dual core, opengl, d3d, dual-sli support? Wouldn't having multiple threads for events & rendering push the onus of making sure all code was thread safe onto the developer? They'd have to synchronise access and prevent deadlocks throughout their scripts, for the JMM as much as anything? The reason Swing is single event threaded is because it makes the developers job so much easier, once you're on the EDT concurrency isn't an issue. The trade-off has always been that the occasional long running task needed taking off the EDT, but that was much easier than making all your code thread-safe.

Besides which as you pointed out JavaFX embeds Swing components and therefore can't get too clever about rendering without fixing Swing first. As JavaFX 1.0 has been released such decisions can't possibly be changed, not ever without breaking backwards compatibility. Which as you've already stated is impossible..

Osvaldo Doederlein replied on Sat, 2009/01/03 - 12:29pm in response to: Richard Osbaldeston

[quote=osbald]

But JavaFX is for all devices isn't it? how many mobiles will have dual core, opengl, d3d, dual-sli support?

[/quote]

That's why FX has separate desktop and mobile profiles. Anyway, most modern Java ME devices have accelerated 3D graphics, video etc., of course not in the same level of a desktop video card, but sufficient for the limitations of the devices. You don't need a ton of CPU+GPU power to run decent graphic SFX - even 3D - on a 320x240 screen; so Java FX Mobile will be fine there. On the threading issue, this is obviously a idea for desktop only. The desktop and mobile runtimes already have different implementations, they can use radically different architectures (like single vs. multithreaded rendering) provided that these don't affect application compatibility.

[quote=osbald] 

Wouldn't having multiple threads for events & rendering push the onus of making sure all code was thread safe onto the developer? They'd have to synchronise access and prevent deadlocks throughout their scripts, for the JMM as much as anything?

[/quote]

No, quite the opposite. Some aspects of Java FX like declarative structures and lazy data binding are sufficient to avoid all need of explicit synchronization in app code. You'd have to sync stuff only if you create your own threads, or if you usenon-standard programming techniques (like pushing state changes to visual components without bound varibles).

 

[quote=osbald] 

The reason Swing is single event threaded is because it makes the developers job so much easier, once you're on the EDT concurrency isn't an issue.

[/quote] 

Not really. GUI toolkit designers have been trying to create multithreaded toolkits since stone age, but they can't solve the problem of inverse propagation of control: events propagate "bottom-up" in the hierarchies, while application calls propagate "top-down". Each propagation often requires the acquisition of locks that protect the state of the component tree; but in inverse order, which makes deadlocks virtually impossible to avoid on toolkits of significant complexity.

[quote=osbald]

Besides which as you pointed out JavaFX embeds Swing components and therefore can't get too clever about rendering without fixing Swing first. As JavaFX 1.0 has been released such decisions can't possibly be changed, not ever without breaking backwards compatibility. Which as you've already stated is impossible..

[/quote]

As I understand it, FX reuses only the view layer of Swing (the rendering code from Swing LAF objects). I'll be surprised if complex pieces of Swing, like DnD, work on top of FX. But in the worst case, the multithreaded pipeline could be optional and not available for programs that use anything from Swing. Future FX releases will introduce a complete package of "native" (scenegraph-based) components.

eugene backs replied on Mon, 2009/06/15 - 6:53am in response to: Richard Osbaldeston

It seems that the dam broke at Devoxx in December. We got some clear direction on the expected timeline and what features will be in and out. There will be a Java 7 preview build available by JavaOne 2009 and theoretically an official Java 7 by January of 2010. I say theoretically because there still seem to be a lot of question marks to fill in pretty quickly.

 

cheers,

residential mailboxes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.