Stuart Marks wrote:
Hi all,
As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK
libraries to use the new JDK 7 Coin features. The first feature is the
diamond operator [2]. This first round of changes includes java.lang,
java.io, java.sql, java.util, their corresponding tests, and related
implementation files (exclusive of java.util.concurrent and related
files). This change touches a total of 71 files. This is rather a lot
of files, but the changes are all one-liners, and most files have only
a few changes.
Lance, please review the change to
src/share/classes/java/sql/DriverManager.java.
Joe, Alan, please review the rest of the changes.
For the curious, I'm using a Jackpot-based automated converter to make
bulk changes to large numbers of source files. I plan to do diamond
conversion of a few other groups of JDK library packages before moving
on to other Coin features.
For verification, it turns out that diamond conversion doesn't change
the bytecodes that are emitted by the compiler, so the resulting class
files are byte-for-byte identical to class files from before the
change. This should make us pretty confident that the changes don't
break anything. Unfortunately, other Coin features will change
bytecodes, so we won't be able to use this easy verification technique
when we apply other Coin features.
The webrev is here:
http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/
Looks good to me, and very easy to review.
One question on this. There are a couple of places where the original
statement was "too long" to fit on a single line so the RHS of the
assignment was pushed into a second line. With diamond it means that the
statement could fit on a single line. Examples are in
java.lang.Character at L649 and the changes to java.lang.Package. It's
purely a style thing but I wonder if the automated converter can do this
re-formating or whether we just leave it for future maintenance in the
respective area?
-Alan.
