Java goes GPL

[Bad Sector]

...according to this article (http://www.crn.com/sections/breakingnews/breakingnews.jhtml;?articleId=193600331) Sun will release Java ME and Java SE under GPL and Java EE under CDDL (the same license as OpenSolaris).

This is good news for those who create Java games, because now you can legally mess with the JRE to minimize deployment sizes :-). I like Java, but deploying 10MB extra is not something i like doing :-P.

I suspect that some developers may also work on creating bare-bones Java runtimes, etc (although Sun is working on a modular system for that). I for once, would like to see a configuration of LWJGL running on top of a 2-3MB JRE.

I think that great times are coming for Java :-)

[voxel]

I've avoided Java for a while due to poor performance when I last used it (1999). Can you point me to some modern Java games that are fast and responsive? I might be a RE-convert...

[Bad Sector]

1999 Java is painfully slow. I don't know if it even has basic JIT or does bytecode interpretation all the time.

Check out Princec's games, they're all in Java. Also there was some FPS written in Java, but i don't remember the url (chrome or something like that).

[Mike]

I've avoided Java for a while due to poor performance when I last used it (1999).
I avoid buying a car because the last time I drove a car,
in 1907, it was so slow that a bicycle could put up with it.

Sorry, I couldn't resist ...

1999 ? Come on, that was SEVEN years ago !.. :rolleyes:

Yes, Java was slow many years ago.
But not anymore, the performance has improved very,
very much since that.

[voxel]

1999 ? Come on, that was SEVEN years ago !.. :rolleyes:

Yes, Java was slow many years ago.
But not anymore, the performance has improved very,
very much since that.

I'll take a look at it again... I started on it during the alpha/beta days in 1996. JIT didn't help performance much. The achille's heel of Java is it's bad memory management and inefficient use of memory. Even ignoring cyclic references that can't be garbage collected, Java was a memory pig. I hope it has reformed. One of the first things you write when developing memory efficient games (i.e for consoles) is a memory allocator to prevent fragmentation. Yes, memory can be fragmented like hard-drives.

Another tech I had high hopes for was Python + pygame but pygame's software rasterizing was way too slow for commercial games. Python + OpenGL should be usable tho'...

[oNyx]

A lot happend since 1999. Back then jit was something fresh n new and it didnt really work that well yet. 1.4.2 (mid 2003) was the first rather cool version of java. 1.5 gave the next performance boost and now there is 1.6, which again boosted performance drastically (in some extreme cases its 48% faster).

Nowadays the garbage collection is very advanced and performance is about on par with the cheaper C++ compilers (after warmup of course). If you take the massive productivity gain into account the performance difference is negligible.

The memory overhead is something like 8mb for the vm and something like 40 bytes per object (not that different compared to C++). The memory hog image comes from the way the VM allocates ram. At startup it allocates a big chunk (size can be overrided with switches, but if you actually need that much or more you only slow it down a bit) and allocation and deallocation of ram also happens in rather big chunks. Every managed language does that for performance reasons. Mananging the ram internally is simply way quicker and you can also prevent memory fragmentation like this.

Cas' Titan Attacks takes for example around 80mb iirc, which isnt much of a problem... even for my very dated 6.5+ year old hardware. Oddlabs' Tribal Trouble for example also runs on that hardware.

Together with OpenGL, OpenAL and Input wrappers (lwjgl or jogl/joal/jinput) its really a pretty neat platform.

[princec]

Hurrah! Finally my VM will be legalised... but under GPL. I suspect that means that all my source code linking to it needs to be open source too? Where does that stand?

Cas :)

[mot]

I was about to ask you that.

[princec]

It's not that I mind particularly... I mean, I've given away all the source code to my games anyway... just I'm not quite sure where the line is drawn with VMs. The VM is technically not linked to the bytecode. Bytecode's just data.

Cas :)

[GBGames]

I doubt that Java apps will need to be similarly licensed. It is like running an application on top of a running OS. It's just data, as you say...unless you take code from the VM and incorporate it into your app.

[soniCron]

From the official GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL):If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.

However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.

Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.

A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.

[Daire Quinlan]

Yeah, I didn't know quite what to make of this when I saw it first, but its actually business as usual. The JDK/JRE and all the sun reference implementations of stuff will be dual licensed. So if you want to use Java to make commercial closed source stuff that links to the Java libs then thats ok. I sincerely doubt that sun would shoot themselves in the foot by abruptly demanding that everything linked to the java standard libs be distributed under the GPL ! Although I don't fully understand the hooha about this anyway, its not as though the Java source hasn't been fully available for years under the CDDL anyway.

D.

[electronicStar]

Good news.
That might not seem very dramatic, but that means the Java language can be tweaked legally and IMHO we should see a lot of projects or engines using Java soon.

[voxel]

Nowadays the garbage collection is very advanced and performance is about on par with the cheaper C++ compilers (after warmup of course). If you take the massive productivity gain into account the performance difference is negligible.

Thanks for the update. I'm much prefer using interpreted languages rather than C/C++.

Python/Java/C#/Lua are all valid choices... but my many concern these days is art toolchain and not languages. I want to leverage tools like Flash, Maya, level editors, etc.. as much as possible.

Embedding Java is cool idea... maybe for complex AI/Networking/Web stuff...

[Bad Sector]

It's not that I mind particularly... I mean, I've given away all the source code to my games anyway... just I'm not quite sure where the line is drawn with VMs. The VM is technically not linked to the bytecode. Bytecode's just data.

Cas :)

If only the VM is GPL, then you won't be affected. If the runtime library goes GPL, however, then you are affected. But they may use LGPL with the runtime library or GPL with some exception. Both are common when dealing with open source libraries.

I doubt they will use GPL for everything.

[cybermonk]

This is good news, since I'm currently developing a game using java and lwjgl!

Cas: how do you minimize your JRE and deploy your game with it? I suppose it's not possible to do this on my mac? Like just copying my jars into some package or directory? :)

[Daire Quinlan]

If only the VM is GPL, then you won't be affected. If the runtime library goes GPL, however, then you are affected. But they may use LGPL with the runtime library or GPL with some exception. Both are common when dealing with open source libraries.

I doubt they will use GPL for everything.

nope, They're GPL'ing everything. Read my post above though, Its being released under a dual license, so only if you MODIFY the VM or the libs do you have to distribute under GPL yourself. Otherwise its the same deal as before. This is all legal and above board. GTK for example (IIRC) has the same dual GPL/Commercial license deal (with added complications actually but thats neither here nor there)

D.

[Bad Sector]

GTK for example (IIRC) has the same dual GPL/Commercial license deal (with added complications actually but thats neither here nor there)

No, GTK is fully and only LGPL. Trolltech's Qt is dual licensed, GPL/Commercial but the GPL version comes with QPL (so actually it is GPL+QPL and Commercial) where QPL requires from those who perform modifications to give the copyrights back to original author (Trolltech), so they will have the right to dual license the modifications under the Commercial license.

[princec]

This is good news, since I'm currently developing a game using java and lwjgl!

Cas: how do you minimize your JRE and deploy your game with it? I suppose it's not possible to do this on my mac? Like just copying my jars into some package or directory? :)
No need to do anything on the Mac, just bundle your game up as per the instructions on Apple's dev site and that's it.

On Windows I just kept deleting dlls, and classes from rt.jar, until the game still ran. Got the VM down to 2.5mb compressed, and considering its versatility (even left RMI in it!) it's a pretty good size for the runtime.

Cas :)

[Daire Quinlan]

No need to do anything on the Mac, just bundle your game up as per the instructions on Apple's dev site and that's it.

On Windows I just kept deleting dlls, and classes from rt.jar, until the game still ran. Got the VM down to 2.5mb compressed, and considering its versatility (even left RMI in it!) it's a pretty good size for the runtime.

Cas :)

Actually, this move by Sun could finally make your approach legal and above board (I know you've been kludging the thing with Molebox for a while now) as long as you GPL your source. Your hacked distribution would come under the auspices of a 'derivative work' I'd imagine. Given that you generally release all your sources anyway It wouldn't be too much of a jump. I presume the GPL doesn't require you to distribute the various other bits and bobs ? Images, configuration files, scripts etc etc, as long as you can -build- the original application.

D. (IANAL)

[Brian A. Knudsen]

Just for reference "Tribal Trouble" was made entirely in java and thus easily ran on OSX and PC. They made a sales posting somewhere on the net, try search for 'oddlabs / tribal trouble'.

best regards
Brian

[oNyx]

Looks like its official that the license will be GPL v2.

http://www.eweek.com/article2/0,1895,2055994,00.asp

Specifically, Sun is releasing an implementation of Java SE in the Java.net community: Java HotSpot technology, the Java programming language compiler and JavaHelp software.

The company also expects to release a buildable JDK in the first quarter of 2007, following established free software community practices for licensing virtual machines and their associated libraries.

[...]

Through the OpenJDK project, developers will be able to directly influence the future of the JDK implementation, participate with their peers in an open community and help take Java technology where it hasn't been before.

There are also other bits about J2ME, GlassFish and J2EE.

[Bad Sector]

It's real. Java is now fully GPLv2, with the "Classpath exception":
Q:
What is the Classpath exception?
A:
The Classpath exception was developed by the Free Software Foundation's GNU/Classpath Project (see http://www.gnu.org/software/classpath/license.html). It allows you to link an application available under any license to a library that is part of software licensed under GPL v2, without that application being subject to the GPL's requirement to be itself offered to the public under the GPL.

So, even if you modify JRE to make it smaller, you don't have to release your sources - only make the JRE modifications available for anyone who will ask :-).

[electronicStar]

Good stuff :)