Linked by kap1 on Thu 25th Apr 2013 11:45 UTC
Java The Lightweight Java Game Library provides a simple API to OpenGL, OpenAL, OpenCL and Game Controllers enabling the production of state of the art games for Windows, Linux and Mac. Version 2.9.0 contains a complete rewrite of the mac backend, support for FreeBSD, new OpenGL/OpenCL extension and bug fixes. The library is used by many high profile games such as Minecraft, Spiral Knights, Revenge of the Titans, Project Zomboid, Starsector, JMonkeyEngine, etc.
Order by: Score:
Probably going to get bashed for this
by lucas_maximus on Thu 25th Apr 2013 12:19 UTC
lucas_maximus
Member since:
2009-08-18

If people are wanting to write cross platform games, Mono Game is probably a better option.

Bastion is one notable example of an indie game that uses it.

Reply Score: 3

Savior Member since:
2006-09-02

Probably going to get bashed for this


Yes, you will...

If people are wanting to write cross platform games, Mono Game is probably a better option.


... because you just dropped this without any hint as to why Mono would be better. I, for my part, would not like to see Mono on my machine -- although I must admit, Java has lost most of its appeal now that it's fallen into Oracle's clutches.

Either way, I think the argument is moot anyway, as Unity runs on all three platforms.

Reply Score: 4

Neolander Member since:
2010-03-08

Not defending the OP, his post was indeed lacking argumentation regarding why Mono Game would be a better option than Java equivalents. But if I were to write a multiplatform game in a managed language, I'd probably also look in the direction of Mono-based tech first.

First because Java runtimes are cursed with suckiness on almost all platforms where I've had the displeasure of dealing with them. The Windows JRE is the textbook example a user-hostile piece of garbage, Linux runtimes may or may not work in a seemingly random fashion, the mere idea of installing the JRE on iOS or Windows Phone is banned by the respective platform owners, and thanks to OS X 10.8's "Gatekeeper" feature I'm not even sure that one can still install the JRE on a Mac without tweaking system preferences. In short, the only major consumer platform where Java software works well today and should continue to work well tomorrow is Android, because it's Java-based itself.

Meanwhile, the Mono runtime works okay on every platform which I've tested it on, and you can very easily statically link it to executables so as to ease deployment to "annoying" platforms like iOS (even if you need to keep the terms of the LGPL in mind when doing so).

Also, the Unity toolchain, which you mentioned yourself, is Mono-based, and it's miles ahead of anything Java-based which I know of. The main difference being that it's not just a set of libraries targeted at game development, but rather something closer to a full multiplatform game development toolchain.

I'm not saying that there is something intrinsically wrong with the Java language or that it's impossible to write good games in it, mind you. I've played several very nice games written in Java. I'm only arguing that the Java ecosystem seems less suitable than the Mono one for that specific purpose.

Edited 2013-04-25 14:05 UTC

Reply Score: 5

moondevil Member since:
2005-07-08

There are a few native compilers worth mentioning like

- Avian (http://oss.readytalk.com/avian/)

- RobotVM (http://www.robovm.org/)

- CodenameOne (http://www.codenameone.com/)

What I don't understand is why Sun, now Oracle, make it such a strong political issue not to offer AOT compilation on their SDK. Specially when it is part of the SpotVM and embedded Java SDKs.

Just let it be like most environments for FP languages and offer JIT + AOT options to developers.

Once I read in a forum post from someone stating internal information that this was a big political issue inside Sun, not sure if it is really true.

Reply Score: 3

snowbender Member since:
2006-05-04

First because Java runtimes are cursed with suckiness on almost all platforms where I've had the displeasure of dealing with them. The Windows JRE is the textbook example a user-hostile piece of garbage, Linux runtimes may or may not work in a seemingly random fashion,..


It seems to be very trendy to bash Java these days. Do you care to explain why you think the Java runtime on Windows is a textbook example of a user-hostile piece of garbage? I also don't understand why you think Linux runtimes may or may not work in a seemingly random fashion.

I have used the Oracle JVM on both Windows and Linux and never experienced any problems with those. I have used the IBM JVM on linux and did experience some compatibility issues. Finally, I've also used the OpenJDK on linux. With the OpenJDK I noticed some warnings from software that insists it wants Oracle JDK (Intellij IDEA), but I didn't really notice any incompatibilities.

... the mere idea of installing the JRE on iOS or Windows Phone is banned by the respective platform owners, and thanks to OS X 10.8's "Gatekeeper" feature I'm not even sure that one can still install the JRE on a Mac without tweaking system preferences. In short, the only major consumer platform where Java software works well today and should continue to work well tomorrow is Android, because it's Java-based itself.


The drawback of relying on locked down systems, is living with the fact that someone else decides for you which piece of software you are allowed to run.

Android is not really "Java-based". A lot of Android aplications are written in a programming language with the same syntax as Java, but they run on the Dalvik VM, which is a different thing than a JVM. AFAIK, you cannot just run any piece of Java software on Android.

Meanwhile, the Mono runtime works okay on every platform which I've tested it on...


No comments about the availability of the appropriate libraries, since I am not familiar enough with those. However, I believe that the JVM is a lot more advanced, and a lot more powerfull and performant than the Mono runtime. I would expect that to be a drawback for games. Maybe it doesn't matter that much when most of the work is actually done in the external libraries that are themselves written in C or C++.

Edit: Ok, also interesting to know that "Mono Game" is an open source implementation of the Microsoft XNA4 Framework.

Edited 2013-04-26 01:19 UTC

Reply Score: 2

moondevil Member since:
2005-07-08

People keep mixing up Java, the language, with the virtual machine that is part of the Oracle Desktop Java Runtime.

I miss the days people really had a clue about languages and implementations.

Nowadays one needs to explain that all the time.

Reply Score: 3

Neolander Member since:
2010-03-08

My guess is, that's because Java is a proprietary programming language where Sun/Oracle's runtime is the de facto standard while other runtimes are second-class citizen.

In almost all other widespread programming languages, you have a clear-cut and well-documented separation between what constitutes the programming language and what constitutes the platform behind it.

This way, standardized languages can exist independently from their creators, and implementations only differ by how well they implement the language and/or standard library. This is not the case with Java: in the unlikely case where Oracle would go bust tomorrow, the Java ecosystem would likely implode for lack of direction, although Google might manage to pull off a "Dalvik is not Java" and save the Android part of it.

Edited 2013-04-26 07:01 UTC

Reply Score: 2

moondevil Member since:
2005-07-08

My guess is, that's because Java is a proprietary programming language where Sun/Oracle's runtime is the de facto standard while other runtimes are second-class citizen.


This is not true for any Java certified VM or native compiler.

Reply Score: 3

Neolander Member since:
2010-03-08

"My guess is, that's because Java is a proprietary programming language where Sun/Oracle's runtime is the de facto standard while other runtimes are second-class citizen."

This is not true for any Java certified VM or native compiler.

What is different about those?

Reply Score: 1

Neolander Member since:
2010-03-08

It seems to be very trendy to bash Java these days. Do you care to explain why you think the Java runtime on Windows is a textbook example of a user-hostile piece of garbage?

My pleasure!

From the very first time you run the JRE installer on Windows, you are greeted with an installer with ugly nonstandard controls and lots of unnecessary clicks, that tries to install crapware in an opt-out fashion somewhere in the middle. This is kind of a great way to leave a first impression, in my opinion.

After that, since the Windows JRE is almost as full of security holes as Adobe Reader, it has to be updated very frequently. The availability of frequent updates would be a good thing, if only the updating process was quick and seamless. Only, it's not. You have to fetch a new version of the runtime manually, retrieve it, run it, go through the installation process all over again, and remind to uncheck the checkbox somewhere that still tries to install crapware on your machine even if you said no the first time.

And obviously, you can't do all that as a regular user, so if you want your machine to stay secure you have to keep typing your administrator password over and over again, all the time. That's quite the way to keep it a secret from others... and if you don't have admin rights on your machine and the admin never logs in by himself, you're basically screwed with an outdated version of one of the top exploited pieces of Windows software.

Oh, right, but will Java software run well on the JRE? At least it does, if you are very patient. Because every piece of Java software which I've had to deal with, no matter how simple it was, took a very long time to start, and then popped multiple warning about unknown security certificates even when I told it that it was a trusted one. Seems like the "remind this certificate" checkbox does not work well for some reaon, so in the end you end up enrolling certificates manually in the impossibly ugly and convoluted runtime configuration windows.

I also don't understand why you think Linux runtimes may or may not work in a seemingly random fashion.

I have used the Oracle JVM on both Windows and Linux and never experienced any problems with those. I have used the IBM JVM on linux and did experience some compatibility issues. Finally, I've also used the OpenJDK on linux. With the OpenJDK I noticed some warnings from software that insists it wants Oracle JDK (Intellij IDEA), but I didn't really notice any incompatibilities.

You are definitely more lucky than me then. In my experience, the Sun/Oracle JVM has been as much of a pain to deal with on Linux as every other piece of proprietary software, meaning that if you can't find a friendly someone who maintains a stable repo for your distribution, it will be painful to install and likely to break on the first slightly significant system update.

Meanwhile, OpenJDK, while it behaved as a good Linux citizen on its side, would frequently refuse to run some software altogether without an explanation (command line aborts without an error message, browser applets silently crash and leave a gray box behind). However, it is true that when software did work, it would work fairly well, save for the occasional app here and there where Unicode text is replaced by a wonderful stream of while box for some reason.

Android is not really "Java-based". A lot of Android aplications are written in a programming language with the same syntax as Java, but they run on the Dalvik VM, which is a different thing than a JVM. AFAIK, you cannot just run any piece of Java software on Android.

My point was that Android developers dealt mostly with the Java programming language, even if they use a different VM and a different set of underlying libraries, and it seemed to work fine for them.

No comments about the availability of the appropriate libraries, since I am not familiar enough with those. However, I believe that the JVM is a lot more advanced, and a lot more powerfull and performant than the Mono runtime. I would expect that to be a drawback for games. Maybe it doesn't matter that much when most of the work is actually done in the external libraries that are themselves written in C or C++.

The Mono runtime is indeed quite a bit slower than the JVM, however it also uses a lot less RAM, which can be an important quality on mobile devices. Anyway, as you said, I wouldn't write a strongly performance-sensitive program or library in a VM-based language like C# or Java anyway. Native code does still have an edge for some use cases, even if the gap is closing.

Edited 2013-04-26 08:13 UTC

Reply Score: 2

moondevil Member since:
2005-07-08

I wouldn't write a strongly performance-sensitive program or library in a VM-based language like C# or Java anyway. Native code does still have an edge for some use cases, even if the gap is closing.


There are native code compilers for C# and Java available.

Just as quick example, are you aware that in Windows Phone 8, C# and VB.NET are actually compiled down to native code?

Reply Score: 2

Neolander Member since:
2010-03-08

You are right about that one. These languages are designed for VM work, but nothing prevents one from translating VM bytecode to its native equivalent, no matter how inefficient it can get without the optimizations made possible by knowing the run-time state of the program at translation time.

However I'm not sure that AOT compilation can solve all the performance problems which are frequently encountere with these languages. Besides the issue of context discussed above, it would only eliminate the runtime compilation overhead of the VM, without tackling some other kinds of runtime inefficiencies which are intrinsic to those languages, such as garbage collection cycles.

Edited 2013-04-26 12:07 UTC

Reply Score: 2

moondevil Member since:
2005-07-08

You are right about that one. These languages are designed for VM work, but nothing prevents one from translating VM bytecode to its native equivalent, no matter how inefficient it can get without the optimizations made possible by knowing the run-time state of the program at translation time.


The fact that strong typed languages are usually mixed up with VM implementations is an unfortunate fact from young generations not understanding what compiler design is all about.

Strong typing or automatic memory management have nothing to do with VMs.

Besides the issue of context discussed above, it would only eliminate the runtime compilation overhead of the VM, without tackling some other kinds of runtime inefficiencies which are intrinsic to those languages, such as garbage collection cycles.


Using GC enabled languages means you need to code in a different way, just that.

Malloc and friends can be slower than reference counting/GC implementations, depending on the use cases. Not all compilers for languages with manual memory management have performant heap management.

Since my Oberon and Modula-3 days, I am firmly convinced that it is only a matter of time until the hard code C developers get replaced by developers that appreciate GC enabled systems programming languages, generation change will help the process.

Reply Score: 3

snowbender Member since:
2006-05-04

From the very first time you run the JRE installer on Windows, you are greeted with an installer with ugly nonstandard controls and lots of unnecessary clicks, that tries to install crapware in an opt-out fashion somewhere in the middle. This is kind of a great way to leave a first impression, in my opinion.


Ok, can relate to that, especially about the opt-out thing. Personally, if I would be leading a big company like Oracle I would be embarassed for adding that toolbar thing in their installer.

After that, since the Windows JRE is almost as full of security holes as Adobe Reader, it has to be updated very frequently. The availability of frequent updates would be a good thing, if only the updating process was quick and seamless. Only, it's not. You have to fetch a new version of the runtime manually, retrieve it, run it, go through the installation process all over again, and remind to uncheck the checkbox somewhere that still tries to install crapware on your machine even if you said no the first time.


As far as I know, Oracle Java comes with a piece of software that automatically checks for updates, and will warn you when a new update is available. You do not need to download updates manually. Or at least, that's how it's been for me on windows.

And obviously, you can't do all that as a regular user, so if you want your machine to stay secure you have to keep typing your administrator password over and over again, all the time. That's quite the way to keep it a secret from others... and if you don't have admin rights on your machine and the admin never logs in by himself, you're basically screwed with an outdated version of one of the top exploited pieces of Windows software.


Ok, but you do understand that this is by design, right? Basic OS security prevents regular users to install new software on the machine. So yes, when you want to install new versions of software on windows, you need admin rights. This is even true for updates coming in through "Windows update".

I do doubt about it being one of the top exploited pieces of Windows software. Sure it got a lot of media attention lately, but that is in the first place for the browser plugin. Either way, I do agree it has security issues.

Oh, right, but will Java software run well on the JRE? At least it does, if you are very patient. Because every piece of Java software which I've had to deal with, no matter how simple it was, took a very long time to start, and then popped multiple warning about unknown security certificates even when I told it that it was a trusted one. Seems like the "remind this certificate" checkbox does not work well for some reason, so in the end you end up enrolling certificates manually in the impossibly ugly and convoluted runtime configuration windows.


This really sounds like running applets, in which case the "long time to start" is probably caused by the fact that the bytecode needed to run the Java program must first be downloaded over the internet.

You are definitely more lucky than me then. In my experience, the Sun/Oracle JVM has been as much of a pain to deal with on Linux as every other piece of proprietary software, meaning that if you can't find a friendly someone who maintains a stable repo for your distribution, it will be painful to install and likely to break on the first slightly significant system update.


I honestly never had a Sun/Oracle JVM break on me. I always install proprietary software in a separate folder in /opt.

Meanwhile, OpenJDK, while it behaved as a good Linux citizen on its side, would frequently refuse to run some software altogether without an explanation (command line aborts without an error message, browser applets silently crash and leave a gray box behind). However, it is true that when software did work, it would work fairly well, save for the occasional app here and there where Unicode text is replaced by a wonderful stream of while box for some reason.


The stream of white boxes normally means you do not have any fonts that can represent the given characters. I do notice we have different usage patterns. I have to say that I very rarely need to run applets. And the Java programs that I do run from time to time are Eclipse, Intellij IDEA, JBoss and some small Java programs I work on.

The Mono runtime is indeed quite a bit slower than the JVM, however it also uses a lot less RAM, which can be an important quality on mobile devices. Anyway, as you said, I wouldn't write a strongly performance-sensitive program or library in a VM-based language like C# or Java anyway. Native code does still have an edge for some use cases, even if the gap is closing.

I don't know about the "a lot less RAM" for Mono, but they definitely have different garbage collectors, with the JVM one being a lot more advanced and powerfull. Different garbage collection algorithms can lead to different memory allocation patterns, which can lead to different RAM usage. However, garbage collector performance improves when the garbage collector gets more ram. So while a program that is limited to 1gb of ram needs to spend 2 minute on GC in total, it is very well possible that with 2gb of ram, it would only spend 1 minute on GC. So in the context of GC using more ram might not necessarily bad, if the ram is actually available.

Either way, thanks for explaining the reasons why you feel so negative about Java and the JVM.

Reply Score: 2

lucas_maximus Member since:
2009-08-18

Mono works on iOS, Android, Linux, Windows, MacOSX.

The Windows Phone SDK works with MonoDevelop.

C# is a better language IMHO than Java (even thought they are both similar).

As I said bastion is a good example of a successful game built using the Framework.

Edited 2013-04-26 16:27 UTC

Reply Score: 3

shiny Member since:
2005-08-09

There are plenty of successfull multiplatform projects using LWJGL, inluding Minecraft, and most of the releases by Puppy Games (Titan Attacks, Ultratron, Droid Assault...)

Reply Score: 4

moondevil Member since:
2005-07-08

Although I prefer stronger type languages, for hobby developers on mobile I would just advice C++, since it is the only language which is supported across all mobile platforms SDKs.

Personally due to personal experience I tend just to use official SDK supported languages.

Too much development effort is lost in writing bindings, plus you never know who to blame when problems arise.

Reply Score: 3

Starsector
by Savior on Thu 25th Apr 2013 13:57 UTC
Savior
Member since:
2006-09-02

Anyway, Starsector completely slipped under my radar. It looks awesome; I'm sure to check it out.

Reply Score: 4

Hahaha
by abstraction on Thu 25th Apr 2013 16:22 UTC
abstraction
Member since:
2008-11-27

There should really be some sort of measurement as to when you are allowed to use the term Lightweight.

I guess a sumo-wrestler in some sense also could be considered lightweight if you only measure him against other sumo-wrestlers...

Reply Score: 0