Reasons why Java is not a good language for game development

[mgianota]

After having read kev’s post on reasons why Java is a good development choice for game programming I felt it necessary to balance things out with a list of reasons why Java is not a good choice.

[1] Native libs. Currently the only way to get decent graphics performance is to use native libraries. Native libraries such as LWJGL rely on the fact that the player has a decent video card, otherwise the library won’t even open up a window. Most PCs have low-end video cards in them.

[2] Java2D’s performance is awful. Even when using the hardware accelerated graphics you still find that the game’s main loop stutters and lags.

[3] Bloated API. Many method names and class names are stupidly, anally long. For example, how many times have you had to type System.out.println(“some string”);? This is a ridiculous amount of typing for such a simple task.

[4] The garbage collector makes games slow and unpredictable. Good time management is a crucial aspect of any game. When you think about it a large chunk of the playability tuning that goes on in game development comes down to adjusting the timed appearance of game objects such as aliens and other moving objects. For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.

[5] Write once, run anywhere is a complete myth. It is write once, debug everywhere and if you are writing applets then that means testing it in IE, Mozilla & Opera running on a combination of Mac, Linux and Windows. Because of the run anywhere myth developers rarely take the time to produce different versions of their software tuned for different machines, something that happens in the C++ world all the time as a matter of routine.

[6] The lack of function pointers is a major pain in the arse. Having no closures is also a major pain. True, Java has anonymous inner-classes but anonymous inner-classes are ugly as Hell; they hang off your code in the editor like a wart.

[7] The security restrictions on applets have rendered them almost useless; you can’t even read and write a temporary cache which means that games can’t save state for the player. Games that force a player to revisit completed levels are a bit lame.

[8] Size. At 14.5Mb the Java runtime is a huge lump of code for a casual game to be dependant upon. Flash games use only a small 1.8Mb runtime.

That’s it for now. I’m sure if I thought about it I could come up with a much longer list, but for the moment I think the above pretty much covers it for me. What are my top hates for programming games in Java? Number one is the stutter and lag closely followed by the garbage collector which cannot be switched off.

–Mario

[bobjob]

@mgianota

[1] Native libraries such as LWJGL rely on the fact that the player has a decent video card

all modern video games rely heavily on the video card

[2] Java2D’s performance is awful. Even when using the hardware accelerated graphics you still find that the game’s main loop stutters and lags.

i wouldnt say awful but it can be a bit slow at times, if someone really wants to get performace out of java2D, there are ways such as using fullscreen exclusive mode. but your right for games, using Java2D probably isnt a good idea.

[3] Bloated API. Many method names and class names are stupidly, anally long. For example, how many times have you had to type System.out.println(“some string”);? This is a ridiculous amount of typing for such a simple task.

I dont see this as a problem as the library is very logical, and can help a new programer learn how to program without knowing every detail.
Programming isnt really a fluid motion, alot of time is spent thinking about what needs to be done. so its not like typing is a real restraint.

[4] The garbage collector makes games slow and unpredictable. Good time management is a crucial aspect of any game. When you think about it a large chunk of the playability tuning that goes on in game development comes down to adjusting the timed appearance of game objects such as aliens and other moving objects. For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.

this is just not true. I have minimul problem maintaining the framerate. but if you find your having problems. Try calling System.gc() after loading, and quiting the realtime play part of the game. also dont load so many resources that java needs to find memory.

[5] Write once, run anywhere is a complete myth. It is write once, debug everywhere and if you are writing applets then that means testing it in IE, Mozilla & Opera running on a combination of Mac, Linux and Windows. Because of the run anywhere myth developers rarely take the time to produce different versions of their software tuned for different machines, something that happens in the C++ world all the time as a matter of routine.

Fair enough, you need to test the application on all platforms you plan to use it. But it is alot easyer in Java than any other lanuage, IMO. I havnt had any problems running my webstart apps on the three main OS’s except for problems in 3th party libraries, which again i find very simple and somewhat fun to fix. Overcoming problems is actually very rewarding.

[6] The lack of function pointers is a major pain in the arse. Having no closures is also a major pain. True, Java has anonymous inner-classes but anonymous inner-classes are ugly as Hell; they hang off your code in the editor like a wart.

ok this is a little dramatic. but if thats really whats holding you back from programming games in java, then I guess its not a language you should use.

[7] The security restrictions on applets have rendered them almost useless; you can’t even read and write a temporary cache which means that games can’t save state for the player. Games that force a player to revisit completed levels are a bit lame.

certificates help, If you are not fimilar with them what they do is give you access to restricted resources. All the user needs to do is click “accept” problems solved. I personally would be scared of a web app that can use any resource via the internet.

[8] Size. At 14.5Mb the Java runtime is a huge lump of code for a casual game to be dependant upon. Flash games use only a small 1.8Mb runtime.

Depends on the quality of the game, if its a big project its hardly noticable. But your right for a simple game it is some what large, but then flash, also requires an install. But once installed it will never have to be done again, well at least not till an update

There are a few impressive games that run really well in Java and i havnt found any problems with performance.
But If the user has an old computer then Yes there will probably be performance issues, and thats why it is great that games warn of specs before distrubition.

[kaffiene]

[1] Que?? All games ultimately rely on the GFX card. You can write to OpenGL or window’s GDI using Java just as well as in any other language.

[2] That’s a good reason to use Open GL. Nothing’s stopping you accessing whatever native apps use via JNI.

[3] HAH! I write games in C++ for a living, and if you think Java is verbose try using the STL! I’d love to be able to use APIs as well designed as Java’s in my game coding.

[4] So, you’ve not used incremental GC?

“For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.” Really? You must be doing it wrong.

Also, with multiple core machines, you can have a non-incremental GC running on another core.

[5] ??? Nothing is stopping you from writing different versions for different targets using Java if you want to. What Java has over c++ is the possibilitiy of getting something that runs on many platforms with much greater ease than any other system around. Shit, we have enough trouble with our C++ code over different service packs of windows let alone being able to run it on Mac or Linux.

[6] Callbacks can be done with interfaces, and are much cleaner and more self documenting if they are. But again, this is NOT a reason why Java sucks for games - its a minor asthetic difference. Closures? Nice, but again - syntactic sugar. Anonymous inner classes are again just a code flavour. Saying ANY of these are important issues really makes me wonder how many games you’ve shipped.

[7] Applets are how 99% of the Java games in the world are NOT delivered.

[8] That’s been fixed in the most recent Java releases, I believe.

Sorry dude, but I think your list is a load of crap. I write games in C++ and it pays the bills, but it’s nowhere the land of milk and honey that you seem to think it is.

[bienator]

[3] you know static imports?
also try:
netbeans sout + tab
eclipse type syso + strg + space

edit:
[4] you can’t expect to put load on a GC and get hard realtime behavior in general.

edit2:
[5] who told you you could write programs without testing in production environments?

edit3:
[6] you can eather (1) think about a language and constantly try to prevent not tracable bugs and security exploits (see buffer overflow) or (2) concentrate on the problem you actually want to solve. The combination: References + GC + simple syntax + a very good compiler which tells you exactly whats wrong leads to 2.

[kevglass]

1 - LWJGL doesn’t rely on a decent card, even the crappiest of the crap intel card gives you some OpenGL. The new Java2D pipeline is also dependent on having a decent graphics card and it performas pretty well now.

2 - See above, the Java 2D pipe is good. The problem is consistency. The performance on different platforms and different VMs varies so much that you can’t rely on it. Thats why alot of us go to natives.

3 - Matter of taste really, personally I prefer explicit declaration over shotcuts, especially with modern IDEs where I don’t have to type any of that anyway. If you want to shorten it a bit I think you could probably do:

import static java.lang.System.out;

4 - Agreed. We still have to do some work to tidy up how bad the garbage collection can get (even with incremental GC) - but then I’d rather do that work that do the work and take the risk of managing the memory myself. I’ve never experienced the extent of the problems you describe but there are definitely plenty of issues here.

5 - Agreed, there’s no doubt at all here. The myth that it “just works” on different platforms is a real pita. I don’t see much need to tune to different platform (since our JVM does that for us) but the lack of testing is a real cause for concern. I worked for a company that believed they didn’t need to test on anything but the development platform simply because they were using Java.

6 - Again matter of taste. I prefer interfaces for these things, function pointers are too low granularity for me.

7 - Agreed, applets are painful. To be fair, it is being worked on, but can’t see that having an impact for a few years.

8 - Like kaffiene said, the Java Kernel project in the latest release is designed to fix that issue. If you’re shipping your own VM you should be able to use the latest (reported as a 3MB kernel?).

I think you’ve got some valid points.

Kev

[EgonOlsen]

[1] Native libs. Currently the only way to get decent graphics performance is to use native libraries. Native libraries such as LWJGL rely on the fact that the player has a decent video card, otherwise the library won’t even open up a window. Most PCs have low-end video cards in them.

And your point is…? My latest game (http://jpct.de/robombs.game) has an optional phone home/call back-function that sends some configuration details and a screen shot. Judging from that, the “native libs (lwjgl in this case)” work fine on Intel crapsets (810, 845, 965,…), on S3 Delta- and Unichrome chips and even on Riva TNT and Geforce2MX. How much lower than this can you get nowadays?

[2] Java2D’s performance is awful. Even when using the hardware accelerated graphics you still find that the game’s main loop stutters and lags.

Personally, i wouldn’t use Java2D for games myself. It wasn’t designed for games in the first place. However, i’ve seen games that use it and run very well, so it obviously IS possible.

[3] Bloated API. Many method names and class names are stupidly, anally long. For example, how many times have you had to type System.out.println(“some string”);? This is a ridiculous amount of typing for such a simple task.

In Eclipse: Type “syso”, press CTRL+SPACE. Too much work for you?

[4] The garbage collector makes games slow and unpredictable. Good time management is a crucial aspect of any game. When you think about it a large chunk of the playability tuning that goes on in game development comes down to adjusting the timed appearance of game objects such as aliens and other moving objects. For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.

That’s just wrong. Garbage collection usually isn’t a problem even on low end machines. Of course you have to take care of some things. If you don’t, then it’s simply “shit in - shit out”.

[5] Write once, run anywhere is a complete myth. It is write once, debug everywhere and if you are writing applets then that means testing it in IE, Mozilla & Opera running on a combination of Mac, Linux and Windows. Because of the run anywhere myth developers rarely take the time to produce different versions of their software tuned for different machines, something that happens in the C++ world all the time as a matter of routine.

I’ve written Robombs on Windows. Once done, i tested it on Mac (PPC and X86), Linux and even Solaris. It worked fine on all of them without changing anything. No need for different versions at all.

[6] The lack of function pointers is a major pain in the arse. Having no closures is also a major pain. True, Java has anonymous inner-classes but anonymous inner-classes are ugly as Hell; they hang off your code in the editor like a wart.

Just syntactical sugar that not even tastes sweet for everybody. You can always find a reason not to do something.

[7] The security restrictions on applets have rendered them almost useless; you can’t even read and write a temporary cache which means that games can’t save state for the player. Games that force a player to revisit completed levels are a bit lame.

Level codes would be a solution. However, i agree that applets suck.

[8] Size. At 14.5Mb the Java runtime is a huge lump of code for a casual game to be dependant upon. Flash games use only a small 1.8Mb runtime.

Size is an issue, but on the other hand, even the drivers(!) for my graphics cards are between 35 and 80mb and require the .NET runtime in addition.

[Mr_Light]

[3] Can you come up with a better example, System.out.println(…); is what you use for console interaction. I almost never use that method, except for the occasional example code. For debugging use a debugger, for logging use a logger… :-X

[4] Never really been a problem for me, even so the effort you have to invest to fix it pales by the required effort you create by removing it.

[5] yes though I must note that your overly enthusiastic picture about ‘the other side’ also write once run everywhere was abandoned anyway. Have fun recompiling for 64bit have fun recompiling to take advantage of other architectural improvements. your slowing down innovation. But then again who cares, any non casual game only have a lifespan of what 4 years max?

[6] ‘Meh’

[7] cookies, chocolate cookies

[8] I don’t know as said there is kernel project but biggest problem is ease of install and distracting toolbar and openoffice stuff update all being too intrusive. They started flirting with microsoft perhaps they can fix something windows update I don’t know where that is going.
@ EgonOlsen, try HP’s 135 mb print driver, I shit you not.

[gouessej]

@mgianota

After having read kev’s post on reasons why Java is a good development choice for game programming I felt it necessary to balance things out with a list of reasons why Java is not a good choice.

Have you been payed by Microsoft or Adobe to be so defeatist?

@mgianota

[1] Native libs. Currently the only way to get decent graphics performance is to use native libraries. Native libraries such as LWJGL rely on the fact that the player has a decent video card, otherwise the library won’t even open up a window. Most PCs have low-end video cards in them.

JOGL works fine even with low-end video cards, I succeeded in playing with my own game with old onboard graphics supporting only OpenGL 1.2. It is even possible to open a frame with a simple canvas even with a graphics card supporting only OpenGL 1.1.

@mgianota

[2] Java2D’s performance is awful. Even when using the hardware accelerated graphics you still find that the game’s main loop stutters and lags.

It depends on the way you use it too.

@mgianota

[3] Bloated API. Many method names and class names are stupidly, anally long. For example, how many times have you had to type System.out.println(“some string”);? This is a ridiculous amount of typing for such a simple task.

If you don’t like Java, nobody forces you to use it. In C#, it is almost the same (Console.WriteLine("…");).

@mgianota

[4] The garbage collector makes games slow and unpredictable. Good time management is a crucial aspect of any game. When you think about it a large chunk of the playability tuning that goes on in game development comes down to adjusting the timed appearance of game objects such as aliens and other moving objects. For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.

It is wrong. In the worst case, you can choose the maximum length of the pause caused by the garbage collector. If you were right, it would be impossible to write 3D games in Java. Jake2 and Avengina prove that you’re completely wrong. Even on low end machines, I rarely have some problems of lag even with complex 3D scenes with collisions.

@mgianota

[5] Write once, run anywhere is a complete myth. It is write once, debug everywhere and if you are writing applets then that means testing it in IE, Mozilla & Opera running on a combination of Mac, Linux and Windows. Because of the run anywhere myth developers rarely take the time to produce different versions of their software tuned for different machines, something that happens in the C++ world all the time as a matter of routine.

Applet support is not very good but you can write heavy applications using Java Webstart, it is less buggy. It is very rarely required to adapt the Java source code to each platform.

@mgianota

[6] The lack of function pointers is a major pain in the arse. Having no closures is also a major pain. True, Java has anonymous inner-classes but anonymous inner-classes are ugly as Hell; they hang off your code in the editor like a wart.

Lol is it a joke? Closures and functions pointers are not very useful, you can easily write a game without them.

@mgianota

[7] The security restrictions on applets have rendered them almost useless; you can’t even read and write a temporary cache which means that games can’t save state for the player. Games that force a player to revisit completed levels are a bit lame.

I don’t give the advice to create “true” games in applets, it is enough for casual games that don’t need to suggest to save a party. Otherwise, use at least a signed applet. Some players might be afraid of it but if they trust you, if they really want to play with your game, they will test it even with the annoying security popup.

@mgianota

[8] Size. At 14.5Mb the Java runtime is a huge lump of code for a casual game to be dependant upon. Flash games use only a small 1.8Mb runtime.

850 000 000 desktop computers are already Java-enabled, it is not a problem.

@mgianota

That’s it for now. I’m sure if I thought about it I could come up with a much longer list, but for the moment I think the above pretty much covers it for me. What are my top hates for programming games in Java? Number one is the stutter and lag closely followed by the garbage collector which cannot be switched off.

Do you really know how a pauseless garbage collection would work? You can already monitor a bit the garbage collection and you should choose data types that don’t require frequent garbage collections. It is mostly a list of prejudices against Java, it is not very constructive. I’m fed up with this defeatism.

As a conclusion, I tell you all that I love cross-platform game programming with Java ;D Keep cool. Yes we can!

[Mr_Light]

@gouessej

Have you been payed by Microsoft or Adobe to be so defeatist?

…

I’m fed up with this defeatism.

Discussion is always good, know thyself is not a bad credo either. Identifying problems is the first step to solving them. etc

I think we don’t want to come across as too harsh, feedback any feedback is important enough to be considered. Even if it where totally off-base perception is important too. You actually need ppl to come into your shop before you can sell them anything ey?

[Orangy_Tang]

Don’t muffins work with applets as well as webstart apps? That would solve number 7 quite nicely.

[Mr_Light]

@Orangy Tang

Don’t muffins work with applets as well as webstart apps? That would solve number 7 quite nicely.

Ne, cookies you should have acces to Js after all from an applet.

hmm according to this it should also work in webstart, considering I haven’t used it - but it was mentioned before and no one is mentioning it now, it might not work as expected. Perhaps I’ll toy with it when I have time.

[CaptainJester]

@mgianota

[3] Bloated API. Many method names and class names are stupidly, anally long. For example, how many times have you had to type System.out.println(“some string”);? This is a ridiculous amount of typing for such a simple task.

C library
strncmp() let’s see is that the binary safe compare or the case sensitive, no wait it is the case insensitive.
Java library
String.equals();
String.equalsIgnoreCase();

• tough one

@mgianota

[4] The garbage collector makes games slow and unpredictable. Good time management is a crucial aspect of any game. When you think about it a large chunk of the playability tuning that goes on in game development comes down to adjusting the timed appearance of game objects such as aliens and other moving objects. For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.

I dare you to find a game at http://www.puppygames.net/ and say that.

@mgianota

[5] Write once, run anywhere is a complete myth. It is write once, debug everywhere and if you are writing applets then that means testing it in IE, Mozilla & Opera running on a combination of Mac, Linux and Windows. Because of the run anywhere myth developers rarely take the time to produce different versions of their software tuned for different machines, something that happens in the C++ world all the time as a matter of routine.

Usually only a problem when you use non-standard libraries. Ask CAS(http://www.puppygames.net/) how much problem he has once he has released a game.

[Orangy_Tang]

@Mr_Light

Ne, cookies you should have acces to Js after all from an applet.

hmm according to this it should also work in webstart, considering I haven’t used it - but it was mentioned before and no one is mentioning it now, it might not work as expected. Perhaps I’ll toy with it when I have time.

No no, I mean muffins, also known as PersistanceService. Think “large cookies for webstart”.

This suggests that if you use the new applet plugin for 1.6 then you get access to webstart/jnlp features, so muffins should be usable.

[Mr_Light]

hmmm muffins.

[quote]access to advanced JNLP extensions previously available only to Java Web Start software applications. A small set was previously available, with restrictions, and these restrictions have now been removed.
[/quote]

[princec]

I can’t say that I agree with most of the OP’s original reasons, except for JRE size and code signing certs.

I would probably like to add some of my own though, which are:

1. The well-documented trouble with getting applets to work reliably.
2. The trouble with signed applets popping up a security dialog.
3. Failure of portability to consoles. The main reason Java has not taken off in this space in fact.
4. Mapped objects in buffers sure would make networking and graphics code a hell of a lot easier to write.

Cas

[Riven]

[quote]After having read kev’s post on reasons why Java is a good development choice for game programming I felt it necessary to balance things out with a list of reasons why Java is not a good choice.
[/quote]
Kev’s post exists for the sole reason of balancing things out, because of the threads regarding major problems with applets.

So now you messed up the balance, and somebody must create a new ‘hurray for java’ thread all over again.

[kevglass]

Why not just duplicate the old one and call it something else? I mean it worked for Microsoft and C# didn’t it? ;D

Kev

[mgianota]

Hmm… Perhaps I shouldn’t have bothered with a list of points and simply published some test code instead to show you my number one reason for not using “pure” Java to write games. Below you’ll see some test code that opens up a window on screen and attempts to move a filled rectangle left to right on screen at 60fps. The result stutters and lags. There’s also some tearing in evidence which is not supposed to happen as BufferStrategy purportedly checks the vertical retrace before drawing. Also, despite the fact that the main loop codepath doesn’t change you can clearly see the FPS indicator moving around between 59 and 40 frames per second.

package gameloop;

import java.awt.*;
import java.awt.event.KeyEvent;
import java.awt.image.BufferStrategy;
import java.awt.event.KeyListener;

/**
 *
 * @author Mario
 */
public class Main implements KeyListener {
    private static Color[] COLORS = new Color[] {
        Color.red, Color.blue, Color.green, Color.white, Color.black,
        Color.yellow, Color.gray, Color.cyan, Color.pink, Color.lightGray,
        Color.magenta, Color.orange, Color.darkGray };
    Frame mainFrame;
    long lastTime;
    int fps;
    int frameCounter;
    long elapsedTime;
    long delayTime = 0;
    Rectangle rect;
    
    public Main(GraphicsDevice device) {
        try {
            // Setup the frame
            GraphicsConfiguration gc = device.getDefaultConfiguration();
            
            mainFrame = new Frame(gc);
            mainFrame.setUndecorated(true);
            mainFrame.setIgnoreRepaint(true);
            mainFrame.setVisible(true);
            mainFrame.setSize(640, 480);
            mainFrame.setLocationRelativeTo(null);
            mainFrame.createBufferStrategy(3);
            mainFrame.addKeyListener(this);
            
            // Cache the buffer strategy and create a rectangle to move
            BufferStrategy bufferStrategy = mainFrame.getBufferStrategy();
            rect = new Rectangle(0, 100, 50, 50);
            
            // Main loop

            while(true) {
                long time = System.nanoTime();
                calculateFramesPerSecond();
                
                // Update rectangle co'ords
                rect.x+=4;
                
                if( rect.x > mainFrame.getWidth() )
                    rect.x = -rect.width;
                
                // Draw
                Graphics g = bufferStrategy.getDrawGraphics();
                drawScreen(g);
                g.dispose();
                
                // Flip the buffer
                if( ! bufferStrategy.contentsLost() )
                    bufferStrategy.show();

                // Delay for a period of time equal to 1/60th of a
                // second minus the elapsed time
                elapsedTime = System.nanoTime() - time;
                delayTime = 1000000000L/60 - elapsedTime;
                time = System.nanoTime();
                while( System.nanoTime() - time <= delayTime)
                    ;
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            device.setFullScreenWindow(null);
        }
        
    }
    private void drawScreen(Graphics g) {
        g.setColor(COLORS[0]);
        g.fillRect(0, 0, 640, 480);
        g.setColor(COLORS[3]);
        g.drawString("FPS: "+ fps, 0, 17);
        g.setColor(COLORS[1]);
        g.fillRect(rect.x, rect.y, rect.width, rect.height);
    }
    private void calculateFramesPerSecond() {
        long time = System.nanoTime();
        if( time - lastTime >= 1000000000L ) {
            fps = frameCounter;
            lastTime = time; 
            frameCounter = 0;
        }
        frameCounter++;
    }
    public void keyPressed(KeyEvent e) {
        if( e.getKeyCode() == KeyEvent.VK_ESCAPE ) {
            System.exit(0);
        }
    }
    public void keyReleased(KeyEvent e) {
        
    }
    public void keyTyped(KeyEvent e) {
        
    }
    public static void main(String[] args) {
        try {
            GraphicsEnvironment env = GraphicsEnvironment.
                getLocalGraphicsEnvironment();
            GraphicsDevice device = env.getDefaultScreenDevice();
            Main test = new Main(device);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

Whilst the collection of points against using Java for games writing is admittedly a little weak, I think that the code above that uses just Java’s standard APIs clearly shows that it is not worthwhile attempting games in Java without recourse to a native library. Just my two cents worth: if you want to write games in Java then make sure you use a native library such as LWJGL, or JOGL to handle the painting and screen updates.

–Mario

[kevglass]

Works flawlessly here, sure you’re not just suffering from the wonderful nano timer bugs (dual core issues)?

Kev

[princec]

Rock solid here too…

Cas