The formal event known as the JCP Public Review for JSR 270: Mustang
Java SE 6 began last Friday. This is the period during which the
near-final specification is published for all to see and comment upon. At the
end of the thirty-day review period the SE/EE Executive Committee
votes to decide whether the specification may proceed toward the last round of
balloting prior to its Final Release.
The term “Public Review” is a legacy of earlier versions of the JCP in which it named the first point at which specifications were made available for public comment; nowadays that happens with the Early Draft. It’s even more of a misnomer for Java SE 6, which has been developed in a much more public fashion than past releases, starting with the posting of build 12 way back in November 2004.
Recall that JSR 270 is an “Umbrella” JSR, so it doesn’t define specific features itself—instead it lists features defined in other JSRs, or in the concurrent maintenance reviews of the Java SE platform specification.
So what’s new? Here’s a quick summary of the major changes since the Early Draft Review; details are available in the Public Review draft.
- The Reflective access to parameter names feature was dropped when the JSR 270 Expert Group concluded that a more complete approach should be pursued in Java SE 7.
- The Internationalized resource identifiers feature was dropped after a series of nontrivial compatibility issues were identified in the design.
- The Easy-to-use Swing layout manager feature (GroupLayout) was added, by popular demand.
- A policy for the gradual removal of existing features was defined, and the removal of the javax.sound.midi package in a future release was proposed.
(In case that last item got your attention, I’ll have more to say about it shortly.)
As usual, comments on this draft are welcome. The formal Public Review period ends on 25 September, but you can send feedback to the e-mail address listed in the draft at any time.



Can we start removing some of the BadThings(TM) in the core APIs such a "run all finalisers on exit" (or at least making them no-ops).
And can we have a Hashable market interface so that (for new code), the compiler will whine/warn if you use non-Hashable (and possibly mutable or non-final) items as keys where hashCode() has to be properly implemented!
All JDK 8+ of course! B^)
Rgds
Damon
Posted by Damon Hart-Davis on August 30, 2006 at 02:23 AM PDT #
Rgds
Damon
Posted by Damon Hart-Davis on August 30, 2006 at 02:25 AM PDT #
Posted by Mark Reinhold on August 30, 2006 at 09:50 PM PDT #