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: 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.)
- 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
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
- 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
(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
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
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