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
