Feature - Implemented Change target platform from Java 1.4 to something newer.
- Thread starter fronobulax
- Start date
roippi
Developer
I'd certainly be okay with bumping up to 1.5. Generics, foreach loops, variable methods with ellipses, annotations, enumerations... all stuff I'd use.
I'm not a CS guy so I have no grasp on the unintended consequences of doing this. I do know that fewyn's script that builds the .jars once an hour is already 1.6 compatible, so I think this is just a question of Official Support for a newer version of Java.
I'm not a CS guy so I have no grasp on the unintended consequences of doing this. I do know that fewyn's script that builds the .jars once an hour is already 1.6 compatible, so I think this is just a question of Official Support for a newer version of Java.
Do systems stuck with 1.4 get security updates still? If not, then it's probably ok to drop support for them, I think.
holatuwol
Developer
You don't need to worry about me at all, actually, since I've got a laptop running Xubuntu 11.04 that I use for all my document processing stuff (Softmaker 2008 being free is so awesome, and I'm addicted to LaTeX for anything where I don't have to send Word documents). But, if you have any friends that use OS 10.4 on their primary machine (it still works great for web surfing, buying music, and watching movies), it might be a concern for them.
According to the Apple Support website, Mac OS 10.3 hasn't received updates since September 2008. The last time Mac OS 10.4 had a security update was November 2010.
Last edited:
This person reports that they are running 10.3.9. They also seem to say that the .dmg file that I created using hdiutil on my system (running 10.6.8) doesn't mount for them. Perhaps we need to specify an older format, or something, to get an image that will mount on that old a system. Considering that Mac users have never required a .dmg file (much as Windows users don't require a .exe file), that's "annoying" - but not a deal killer.
Upgrading to 1.5 - or 1.6 - or whatever - gives you additional core Java features and additional Library functions. Additionally, 1.4 functions may have bugs in 1.4 Java installations which have been fixed in later Java releases - but that has nothing whatsoever to do with whether we use 1.5 or later features in our code; users can get those bug fixes by upgrading their Java versions regardless of what version we write our code to be compatible with. For example, on my system, "java -version" says "Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)". I have some build of 1.6, with all the bug fixes (and new bugs...) that are implied by that.
I'd like to understand exactly what Java feature or library function is present only in 1.5 or later that it is essential we use.
I can't say that my development has ever been hobbled because I missed something in 1.5+. Not that I would know; I taught myself Java by developing KoLmafia, and 1.4 is all I know.
Upgrading to 1.5 - or 1.6 - or whatever - gives you additional core Java features and additional Library functions. Additionally, 1.4 functions may have bugs in 1.4 Java installations which have been fixed in later Java releases - but that has nothing whatsoever to do with whether we use 1.5 or later features in our code; users can get those bug fixes by upgrading their Java versions regardless of what version we write our code to be compatible with. For example, on my system, "java -version" says "Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)". I have some build of 1.6, with all the bug fixes (and new bugs...) that are implied by that.
I'd like to understand exactly what Java feature or library function is present only in 1.5 or later that it is essential we use.
I can't say that my development has ever been hobbled because I missed something in 1.5+. Not that I would know; I taught myself Java by developing KoLmafia, and 1.4 is all I know.
roippi
Developer
I'll give it a crack, though I'm far from an expert.
First nice thing is added compile-time safety: Generics provide compile-time safety for moving data into and out of collections. This is nice because without it, you can get runtime errors from trying to cast an unexpected type that pops out of a list. Enumerations also are a superior method of representing a fixed set of constants that provide type safety (and other nifty stuff outside the scope of this discussion).
It also provides coding tools that make things cleaner. Foreach loops are nice, no iterator needed. Varargs are also nice: put an ellipsis on the last type declaration in a method and you can pass as many of that type as you want, and it automagically bundles them into an array if there's more than one.
As for library functions: I haven't run into too many situations where I couldn't do something without methods added in later releases, but there were a couple times where I needed 5 lines of code where one would have sufficed - off the top of my head, formatters are useful. There are some enhancements to matchers, fontmetrics, and whatnot. Also the java.util.concurrent package, apparently very useful for dealing with multi-threaded stuff. Not my area of expertise.
Also, much improved XML support.
I'm sure there's stuff I've left out, but tl;dr: it frankly isn't -essential- for anything. It does make for better code and possibly catches some bugs at compile time. The improved html support which I mentioned offhandedly might actually be a pretty compelling reason as well.
I am quoting without verifying but someone made the claim that using a css file or similar construct in the Swing components that display HTML text was feasible in 1.5 or 1.6 but not 1.4. In my current state of ignorance a css file seems to be the best way to handle colored text and associate preferences. Clearly if the information I am trusting is incorrect then this whole discussion is moot.
I want to understand these claims. Are these new 1.5+ only Swing components? New classes/subclasses? New methods on existing (which ones?) classes? Or are these things which those of us whose Java runtime is > 1.4 inherently have, since it will handle HTML better than a 1.4 Java runtime? (If so, intentionally generating HTML that a 1.4 runtime is known to choke on would be making a stealth dependency on 1.5+, wouldn't it?)
Show me the docs, please. Thanks.
Partial answer. It looks to me as if "native" support is provided via the class StyleSheet which is in 1.4.2. The API doc for 1.4, 1.5 and 1.6 all say
This leads to at least three questions which I have no answers to at the moment. First, how do the various versions of StyleSheet differ? Second, can we replace colors and other text formatting in mafia text with values from a css using any version of StyleSheet? Finally, is there a "complete" implementation available from a third party and does being "complete" make a difference to what we are trying to do?
Unrelated to the css discussion I note that some of the foxtrot package code has "JDK14" in the file name which strongly suggest a version dependency to be investigated if we do change.
roippi?
This leads to at least three questions which I have no answers to at the moment. First, how do the various versions of StyleSheet differ? Second, can we replace colors and other text formatting in mafia text with values from a css using any version of StyleSheet? Finally, is there a "complete" implementation available from a third party and does being "complete" make a difference to what we are trying to do?
Unrelated to the css discussion I note that some of the foxtrot package code has "JDK14" in the file name which strongly suggest a version dependency to be investigated if we do change.
roippi?
roippi
Developer
This one. There actually were no significant changes to swing in 1.5 other than adding look and feels. What changed is how jcomponents handle HTML. Anything with significant XML is likely to be at least partially broken in 1.4-and would be silently broken for anyone developing with a 1.6 jre. Have to run on the old jre to see it.
My recollection is that 1.5 supports XML 1.1. I'm unfortunately on a phone with shoddy service so I cannot link to docs at the moment.
holatuwol
Developer
Not really, a better idea would be to move away from the whole SwingWorker concept altogether. There's really no additional UI processing needed from pushing a button that people wouldn't expect to have happen automatically anyway from the equivalent CLI command / relay browser request.
roippi
Developer
Bump. Hola recently added use of Jstack to mafia's debugging tools[1]. I believe this officially breaks support of Java 1.4. Time to move to 1.5 or 1.6? Since the posting of this thread, things that I have run across:
-"Silent" JRE bugs: I think all of the devs run Java SE 6 or 7. There are differences (especially in swing) in how code can be implemented, or how it will be displayed. For example, recently I was looking into JPopupMenu, and ran into a case where a JPopupMenu implementation would work fine in 1.5 but be completely broken on 1.4. In any case, true "support" of 1.4 would involve devs testing builds on 1.4 JREs, which I think is unreasonable.
-Better coding practices- every time I have to define a boatload of public final static int constants, I cringe a little. A far better solution is enums. I won't go over all the things that enums can do, but they're cool. You can use them in switch statements (awesome), they have type safety, etc. And on the topic of type safety: generics (1.5 feature) turn runtime exceptions into compile-time exceptions. I like it.
-Other stuff- more methods to make code cleaner. I particularly want foreach loops. Every so often there's a method added in 1.6 that can do something in one line what takes five lines in 1.4. Performance improvements, too: for example, see Integer.valueOf( int ) instead of new Integer( int ).
-"Silent" JRE bugs: I think all of the devs run Java SE 6 or 7. There are differences (especially in swing) in how code can be implemented, or how it will be displayed. For example, recently I was looking into JPopupMenu, and ran into a case where a JPopupMenu implementation would work fine in 1.5 but be completely broken on 1.4. In any case, true "support" of 1.4 would involve devs testing builds on 1.4 JREs, which I think is unreasonable.
-Better coding practices- every time I have to define a boatload of public final static int constants, I cringe a little. A far better solution is enums. I won't go over all the things that enums can do, but they're cool. You can use them in switch statements (awesome), they have type safety, etc. And on the topic of type safety: generics (1.5 feature) turn runtime exceptions into compile-time exceptions. I like it.
-Other stuff- more methods to make code cleaner. I particularly want foreach loops. Every so often there's a method added in 1.6 that can do something in one line what takes five lines in 1.4. Performance improvements, too: for example, see Integer.valueOf( int ) instead of new Integer( int ).
bordemstirs
Member
I was wondering if this change could be responsible for some issues that my bots have run into recently (but I couldn't reproduce reliably enough for a legit bug report)
I don't know exactly what revision it started with (10440-10470), but rolling back to 10440 resolved the issue.
I have bots that rely on now_to_string("HHmm") and now_to_string("Z") and, on occasion, the system would completely ignore the arguments and return a full now_to_string() causing the subsequent to_integer() to fail and severely alter the behavior of my buffbots.
However, running the preceding commands from the cli shows expected behavior. The bots just run the same code rather frequently and shortly after starting start throwing the "Blah blah time string isn't an integer; Returning X" error.
I'm running mafia on Windows 7 with JRE 1.6
jasonharper
Developer
I'd like to put in a vote for not going any higher than 1.5, since that's end-of-the-line for my 10.4 Mac.
holatuwol
Developer
While it's not required that I be able to use KoLmafia on my Mac since I have another computer, I'd really appreciate this as well.
wrldwzrd89
Member
Given what's been said so far, moving to Java 5 has my full support. However, I do not think it is worth moving to Java 6 yet... that said, Java 7 (and the forthcoming Java 8) have some new features that KoLmafia could potentially benefit from.
Main changes in JDK 6 were refinements to JDK 5: extended detection of annotations (they now do something useful if applied to overridden methods from interfaces, which wasn't the case in 5), built-in database support (which KoLmafia has no use for), GUI look and feel improvements, and a few other minor things.
Java 7 brings with it: multi-catch blocks, try with resources, strings in switch statements, and several other things not worthy of mentioning. All of these would make KoLmafia's code cleaner if adopted, but lack of production-quality Mac support, along with the developers not all having computers that can support it, is going to hold this change back for a while.
Main changes in JDK 6 were refinements to JDK 5: extended detection of annotations (they now do something useful if applied to overridden methods from interfaces, which wasn't the case in 5), built-in database support (which KoLmafia has no use for), GUI look and feel improvements, and a few other minor things.
Java 7 brings with it: multi-catch blocks, try with resources, strings in switch statements, and several other things not worthy of mentioning. All of these would make KoLmafia's code cleaner if adopted, but lack of production-quality Mac support, along with the developers not all having computers that can support it, is going to hold this change back for a while.