Proposed refactoring: introduce JLS7 language features to core libs

[Martijn Verburg]

Hi all,

> On 4/25/12 12:07 PM, Stefan Reich wrote:
>>
>> Hello,
>>
>> is there any interest to accept change sets based on OpenJDK 7 that update
>> the java classes in jdk/src/share/classes to use
>>
>> * multi-catch
>> * string switch statements as opposed to nested if statements when
>> comparing strings with string literals
>> * type inference by removing duplicative type information in the
>> constructor when using generics
>> * indexOf(int) when indexOf(String) is used with a String literal that
>> contains only one character, and similar small-scale improvements?
>>
>> The proposed change sets would pass all jtreg tests. If there is interest,
>> what would be next steps?
>
>
> Hi, yes, there is interest! Thanks for raising this topic.
>
> In some respects this seems similar to the "Coinification" work [1] I did
> during JDK7 development, that is, to use the then-new Project Coin features
> in the code base of the JDK itself. The goal of that effort was to put some
> of the Coin features to use in production code, so as to gain experience
> with them, but not necessarily to "coinify" the entire source base. In fact
> I've been asked how much of the code base was converted to use the new
> features. The answer is, I don't know. I'm pretty sure that there is a lot
> remaining to be done, though.
>
> (As an aside, most of the warnings work we've been doing over the past
> several months is to clean warnings that result from the use of raw types
> instead of generics. That is, there is lots of code lying around that hasn't
> been updated to Java 5 generics yet! There are similar refactorings one
> could apply for Java 5 language features, such as the enhanced-for loop,
> enums, covariant overrides, autoboxing, etc.)
>
> Probably the easiest feature to get started with is diamond (formally known
> as "type inference for generic instance creation"). It should be fairly
> simple to find lots of examples where this can be put to use, now that there
> are bulk change hints available in NetBeans. (Bulk changes are probably also
> available in Eclipse and IntelliJ Idea.) The good thing about diamond is
> that it is practically impossible to bugs when doing diamond conversion. In
> fact, the resulting class files should be byte-for-byte identical to the
> previous versions. In practice, though, I did join lines where appropriate,
> since using diamond often shortened the code enough to fit on a single line
> where it had to be split across lines before.
>
> There are a small number of stylistic issues that occur when using diamond;
> see [2] and [3]. Different people have different styles, and unfortunately
> different styles have emerged in different areas of code. The main
> difference seems to be whether diamond is used in assignment and return
> statements, where the use of diamond is separated from the variable
> declaration that contains the complete type.
>
> In practice what this means is that you should break down your changesets to
> apply to different functional areas, and then find the right people and the
> right mailing list to discuss the changes beforehand. (Actually this is
> probably good practice for any change, not just diamond.)
>
> Turning to the other suggestions, I'd say that multi-catch and
> strings-in-switch are also fairly safe refactorings to propose, although
> they probably occur much less frequently than diamond. There are some
> subtleties with applying these refactorings, which will require more
> scrutiny than applying diamond changes.
>
> For example, in some cases there is a catch of Exception that is better
> expressed as a multi-catch of several Exception subtypes. This might make
> for better code, but it subtly changes the behavior of the code. For
> strings-in-switch, a null value of the switch expression results in NPE,
> whereas (depending on the details, of course) a cascade of if-elses may end
> up handling null differently.
>
> I'm not sure about the indexOf() cases you refer to. I guess I'd have to see
> some examples before deciding whether these are worthwhile to pursue.
>
> In any case, thanks for taking the initiative to work on this stuff. Looking
> forward to seeing what you come up with.
>
> s'marks
>
> [1]
> http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/
> [2] http://stuartmarks.wordpress.com/2011/01/24/where-can-diamond-be-used/
> [3] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/

FYI, Stefan has kindly offered to join the Adopt OpenJDK program
(http://java.net/projects/jugs/pages/AdoptOpenJDK) and we'll all work
together of pre-review of patches, with Stuart's comments as a
starting guideline.

Cheers,
Martijn