Hi Stuart,
thank you for your reply. I sent a patch to the adopt-openjdk group that uses
multi-catch for catch clauses with duplicate code blocks in the same try
statement (message and patch attached). That patch covers all code in
src/shared/classes. Martijn will help coordinating the effort with all
individual component owners, since I don't know anyone over at the OpenJDK team.
The string switch conversion is relatively straight forward, too. The more
complicated case that you mention:
String s;
if("literal1".equals(s)) {
} else if("literal2".equals(s)) {
} else {
// s is null or some other value
}
is very rare in the OpenJDK code base. I saw only a handful of occurrences out
of 95 files affected by this refactoring (in src/share/classes). If there is
interest, I'd review the changes and create a patch, but I wanted to see how
things are going with my first submission before investing more time.
How far are you with type inference? Are you going to write a NetBeans plugin?
Stefan
--- Begin Message ---
This patch introduces multi-catch to the entire OpenJDK code base. Code that
looked like this before the refactoring:
try {
C.class.getDeclaredMethod("main", null).invoke(null, null);
} catch (IllegalAccessException e) {
} catch (IllegalArgumentException e) {
} catch (InvocationTargetException e) {
} catch (NoSuchMethodException e) {
} catch (SecurityException e) {
}
The code will look like this after applying the attached patch (see below).
try {
C.class.getDeclaredMethod("main", null).invoke(null, null);
} catch (NoSuchMethodException | SecurityException | IllegalAccessException |
IllegalArgumentException | InvocationTargetException e) {
}
The benefits of this refactoring are reduced code size, both source and class
files, enhanced readability and finally it is as a reminder for everyone
writing code that OpenJDK is now a JLS 7 code base. More details are in my blog
post:
http://stefanreich.blogspot.com/2012/04/java-7-multi-catch-statements-under.html
The refactoring has been performed by my eclipse refactoring plugin; I
code-reviewed every change. They compile fine on my Fedora system, jtreg
produces the same number of errors before the patch and after. The patch is
based of OpenJdk 7, changeset: 4971:f7e9f377bb5e from Friday
Please let me know how to proceed with getting this change into the code base.
Cheers,
Stefan Reich
--
You received this message because you are subscribed to the Google Groups
"Adopt OpenJDK" group.
To post to this group, send an email to adopt-open...@googlegroups.com.
To unsubscribe from this group, send email to
adopt-openjdk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/adopt-openjdk?hl=en-GB.
--- End Message ---
On Apr 30, 2012, at 6:52 PM, Stuart Marks wrote:
> 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/
>
>
