Proposed refactoring: introduce JLS7 language features to core libs

[Martijn Verburg]

Hi all,

On 1 May 2012 10:33, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 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

Further to this I've added a page
(http://java.net/projects/jugs/pages/CoinificationOfTheOpenJDK) to
cover our efforts in this area.  Comments/Questions very welcome.

Cheers,
Martijn