code review request for 6880112, Coin: use diamond in core libraries

Kelly O'Hair kelly.ohair at oracle.com
Thu Dec 16 17:34:40 UTC 2010


On Dec 16, 2010, at 12:45 AM, Alan Bateman wrote:

> 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?

But changing the line numbers will change the class file contents. :^(

-kto

>
> -Alan.




More information about the core-libs-dev mailing list