Considering our “audience” (including judging panel) are developers, I don’t think it really matters.
What? The 100,000+ people who’ve played miners4K are all developers?!!! :o
I am constantly amazed at how developers can expend so much energy on minuscle topics like this. Almost 70% of the internet has 1.6 according to those stats, the 8% on 1.5 surely don’t play game applets anyway.
Having said that, I don’t have preference, have fun deciding.
Edit: yes having a bad day at jorb :’(
You do understand some people had to actually install/update Java to play it, right? I remember similar discussions when L4K Dead hit reddit …
Also, 1.5 is EOL. This is a silly discussion really
I don’t mind whether the target is 1.5 or 1.6. The question is whether any of the changes in 1.6 lead to better performance due to compilation improvements or a smaller executable. If not, I’ll target 1.5 since I can then test on my aging mac powerbook. (I’m not feeling like buying a new mac due to certain recent developments)
Edit: I can easily compile to 1.6 on my PC, but can’t test it on my mac as it is an old powerpc mac and apple only supports java 1.5 on that platform. I would need to buy a new intel based mac to get java 1.6, and I’m not about to do that. So… what I wanted to know was if anyone could think of any good reason to target 1.6 rather than 1.5. This doesn’t mean the comp has to have a target of 1.5. If I target 1.5 it should work on 1.6. What I’m trying to figure out is whether to target 1.6 on the PC only (it may or may not work on the mac) or target 1.5 and test on both PC and Mac. The only reason to target 1.6 is if ot contains any new “must-have” features.
At the moment I can’t see any “must haves” in 1.6. Does the marking scheme still consider cross-platform important?
This contest is not about 100% backwards compatibility with outdated JRE’s. We’re not making business critical applications here. It’s primarily a contest by and for the developers, secondary is allowing everyone else enjoy the games. Also, I believe 1.5 is officially End-Of-Life, so anyone that still has it, shame on them.
1.6 it is, at least in my mind 
[quote=“woogley,post:64,topic:35838”]
Killer rhetoric! But you’re right of course; 1.5 is old news. It’s just that I’m a softy & hate the thought of some poor mac-book-bound soul thinking: ‘Awww! I can’t play it!’ - especially when I just spent some time bigging the damn thing up to them… blush
I looked through the changes for 1.6. Library wise, they added more support for scripting languages, some XML stuff, an interface for referencing Java compilers, an updated database framework, annotations, and some helpers for working with Swing. I don’t think anyone has room to include a scripting language, XML is huge, referencing a compiler midway through a game sounds downright bizarre, accessing a database is probably a rules violation, annotations increase your class file size in a way your compressor won’t get along with, and Swing is too bloaty for Java4k. I don’t think we need any of the new libraries. The new VM has some significant performance improvements, especially on low-level stuff so it’s likely especially improved for our purposes. However, I’m pretty sure anybody running 1.6 gets those performance improvements regardless of the version of Java the application was compiled for, so this is no different than our users having differently capable computers.
So I’d vote for sticking with 1.5, because I don’t think there are any advantages to the upgrade.
If, however, anybody thinks of a use for any of the new library features, I’m willing to change my vote. Of the above, I think the new scripting language features are the most promising, since their API seems surprisingly J4k-friendly. Before I head off and run experiments, I have to ask: would using a scripting language be allowed in Java 4k? If parts of your game are written in Perl or whatever, does that violate the idea that the program should be compiled in Java?
I will be participating again this year, and I vote for 1.6.
There have been entries (or a single entry?) in Scala last year, and people have been fiddling with bytecode directly to write their game, for which there wouldn’t be a Java sourcecode representation. I think that it is acceptable to use whatever means to write a game within 4K, that runs on the Java platform. What language you use is entirely up to you.
I think, however, that those scripting languages are likely to produce massive amounts of bytecode. The only real option is to use Rhino (which is embedded in the JRE), and hope your javascript sourcecode is small.
If its going to be java 1.6+ then maybe some javascript code can be added to the site which simply detects if you have an older JRE, if so it displays a message “Java 6 or greater required, please update your java install” or something. Should be less frustrating then it just failing on older jvm’s.
It used to be you couldn’t run Rhino/javascript in an applet with out a security certificate because Rhino required file system access for compiling javascript (iirc). It was way before 1.6 when I played with it though so things may have changed. But yeah, text will compress a lot better than binary data. So you’d have a jar with an applet that launches Rhino with a text file from the jar.
Or maybe Rhino compiles to bytecode. I know that Jython emits code that is java with all the Python features implemented as PyObjects so you’re looking at a massive amount of additional compiled code. So I’m not hopeful that a compiled dynamic language would be economical on space.
AT one point Charles Nutter had a statically type Ruby subset (Duby?) that may compile to some tighter bytecode depending.
Scripting languages? Sure, as long as it’s an executable as in an applet using the current JRE.
It’s really just a resource you’re executing. A resource could be anything, data file, image, script or inline code. A lot of programmers have “created” their own little scripting languages to procedurally generate content within 4k games. Call it some proprietary format, a script or just some hack, the end result is the same.
It will be interesting to see if people can do anything useful with rhino within the restrictions of 4k.
So apparently the notes I read on improvements in 1.6 completely missed the incredibly useful Path2D. That’s more than enough to make me want to switch to 1.6, by itself. So consider my vote switched. Though I think the consensus was already leaning towards 1.6 ;-).
In JDK 1.5, the only zip compression method that’s supported is deflate. A quick test showed me that 1.6 should support the different 7z zip compression methods: deflate64, bzip2, and lzma. Is this a correct assumption, across the different platforms?
Haha, yes, it has bugged me a bit. But it’s not all that bad.
Also: I agree that we should go with 1.6. The main reason for this is that I couldn’t get pack200 to work properly under 1.5, and eventually just skipped using it.
[quote]Also: I agree that we should go with 1.6. The main reason for this is that I couldn’t get pack200 to work properly under 1.5, and eventually just skipped using it.
[/quote]
The Java 1.6 plugin for Mac OS X is not able to load pack200 binaries as far as I know from my own testing. Even if we allow Java 1.6, we’ll still need to supply a normal jar for those users.
Did anyone check if Java 1.6 produces more compact or more bloated class files? If the Compile-And-Shrink service is updated to support Java 1.6 compilation, can there be an option for Java 1.5 as well just in case it produces smaller binaries?
I just ran a quick check on my Linux setup, comparing Sun JDK 1.5.0_22 vs. Sun JDK 1.6.0_22 on several of my 4k games. Both produced the same sized class files.
Edit: turns out I wasn’t running with different compilers. The raw 1.5 compiled classes were smaller than the 1.6, and the final compressed versions were smaller by quite a bit as well.
Edit 2: Running the 1.6 compiler with a 1.5 target + 1.5 rt.jar generated the same sized class files as when running the 1.5 compiler.
Interesting, but you have to be careful to draw conclusions from 1 testcase.
I’ll probably add it to Compile-And-Shrink, unfortunately doubling the processing time.
This was performed with 34 different class files, but your warning still applies - these are only minor changes to essentially 4 different classes.