Proposed refactoring: introduce JLS7 language features to core libs

Stuart Marks stuart.marks at
Tue May 1 01:52:54 UTC 2012

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.





More information about the core-libs-dev mailing list