Proposed refactoring: introduce JLS7 language features to core libs
stuart.marks at oracle.com
Tue May 1 01:52:54 UTC 2012
On 4/25/12 12:07 PM, Stefan Reich wrote:
> 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  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
(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,
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
 and . 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
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