Proposed refactoring: introduce JLS7 language features to core libs

[Stefan Reich]

Hi Stuart,

thank you for your reply. I sent a patch to the adopt-openjdk group that uses multi-catch for catch clauses with duplicate code blocks in the same try statement (message and patch attached). That patch covers all code in src/shared/classes. Martijn will help coordinating the effort with all individual component owners, since I don't know anyone over at the OpenJDK team.

The string switch conversion is relatively straight forward, too. The more complicated case that you mention:
String s;
if("literal1".equals(s)) {
} else if("literal2".equals(s)) {
} else {
// s is null or some other value
}

is very rare in the OpenJDK code base. I saw only a handful of occurrences out of 95 files affected by this refactoring (in src/share/classes). If there is interest, I'd review the changes and create a patch, but I wanted to see how things are going with my first submission before investing more time.

How far are you with type inference? Are you going to write a NetBeans plugin?
 
Stefan

-------------- next part --------------
An embedded message was scrubbed...
From: Stefan Reich <sreich at mac.com>
Subject: Refactoring OpenJDK to leverage multi-catch statements
Date: Sat, 28 Apr 2012 16:09:12 -0700
Size: 6549
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20120501/0b3ce81f/RefactoringOpenJDKtoleveragemulti-catchstatements.eml>
-------------- next part --------------

On Apr 30, 2012, at 6:52 PM, Stuart Marks wrote:

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