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.
Thread beginning with comment 559756
To view parent comment, click here.
To read all comments associated with this story, please click here.
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 Parent 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 Parent 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 Parent Score: 2

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 Parent 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 Parent Score: 2

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 Parent Score: 2