Hi all, On 1 May 2012 10:33, Martijn Verburg <martijnverb...@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
