Java SE 6 Release Contents (JSR 270): Public Review

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.

Comments:

Hi,

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 29, 2006 at 07:23 PM PDT #

Ahem, "marker" interface... The "market" interface would be for my financial clients! B\^)

Rgds

Damon

Posted by Damon Hart-Davis on August 29, 2006 at 07:25 PM PDT #

Damon: No, we aren’t going to remove small random bad things. They’re already deprecated, which is a pretty powerful hint of badness. They’re bad—and in some cases very bad, if not horrid—but removing them or changing them to be no-ops would put working applications at risk for no good reason.

Posted by Mark Reinhold on August 30, 2006 at 02:50 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

This blog has moved to http://mreinhold.org/blog. <script>var p = window.location.pathname.split('/'); var n = p[p.length - 1].replace(/_/g,'-'); if (n != "301") window.location = "http://mreinhold.org/blog/" + n;</script>

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll

No bookmarks in folder

Feeds
RSS Atom