Feature Some migrations to java 1.5

I posted a gigantic (and somewhat unusable) patch a couple of days ago with some java 1.5 upgrades, and got pretty good feedback on it.

I have reworked the changes into one patch per type of change, so that it's easy to cherry-pick what you like and disregard what you don't.

The patches:

http://frikod.se/~capitol/0002-variable-boxing-and-unboxing-that-s-not-needed-in-1..patch

http://frikod.se/~capitol/0003-replaced-StringBuffer-with-the-slightly-faster-Strin.patch

http://frikod.se/~capitol/0004-replaced-indexOf-with-contains-as-it-is-a-bit-more-r.patch

http://frikod.se/~capitol/0005-declaring-all-functions-as-final-doesn-t-add-any-spe.patch

and a link to the branch in my git repo: https://github.com/alexanderkjall/kolmafia/commits/java-1.5-cleanup

Edit: I think i choose the wrong prefix again, sorry about that, it seems like i can't change it?

capitol said:

Edit: I think i choose the wrong prefix again, sorry about that, it seems like i can't change it?

Click to expand...

Normal users can't change those, but I've changed it.

Skimmed patches 1 and 2, they look fine and I'll get around to committing them eventually. I'm kind of ambivalent on the contains() patch and not particularly sold on the final patch. The point of final methods is that they can't be overridden; it conveys intent by the person who coded it.

I'd say since we've moved to 1.5 compliance, contains() is probably worth considering for readability.

For those who are interested, the difference in Java bytecode between the two is the current implementation performs if_icmpeq whereas the proposed change would switch that instruction to if_icmple. The resulting processor instructions are then determined by the JVM at runtime.

The reason i included the final patch was that I suspected that final was added for speed reasons, since there was a number of private methods marked as final and thought it might be enlightening to bring the subject up for discussion.

I'm working on some more usability improvements for the chat, and have also started to think about how generics can be used in the codebase. One of the classes that would enable wider use of generics is the LockableListModel, if we convert that one to support generics then alot of the casts in the interactions with that class can be simplified out, I'll post a suggestion on how it could be done in a day or two.