Java is fast.

berry120

Fully Optimized
Messages
3,434
Location
UK
http://labs.oracle.com/techrep/2002/smli_tr-2002-114.pdf

It's from a while back now but still shows a rather important point and debunks a rather widespread myth at the same time... Well written Java is generally no slower than C. In fact, it's often faster because of how clever the JIT compiler is these days :)

Admittedly these were guys that know the innards of Java better than anyone, but bear in mind this was written almost a decade ago and both the compiler and hotspot VM are a heck of a lot cleverer these days.

How? Well, C code might be platform dependant and native, but it still needs to be written to run on a number of different architectures. The Java VM knows exactly what hardware it's on when it's running your code, and because of this it can do things entirely differently depending on the underlying processor, memory available, the lot. So it can be incredibly specific in its optimisations, and especially using the server VM (which takes a while to start up but is stupidly fast when it does) it does an amazing job at it.

So if you ever hear the rumour / myth flying around that Java is as slow as slugs on depressants, ignore it. The last time it held much truth was in the 90's. When used properly Java is a blisteringly fast language, and continuous improvements mean it's only set to get better!
 
What about graphics? I can usually tell when a UI has been programmed in Java because of its sluggish nature with a tendency not to respond while the JVM is doing other things. Maybe it's just Swing, I'm not sure, but does Java's inability to access native graphics components limit its speed in terms of UI's and graphics-heavy games?
 
What about graphics? I can usually tell when a UI has been programmed in Java because of its sluggish nature with a tendency not to respond while the JVM is doing other things. Maybe it's just Swing, I'm not sure, but does Java's inability to access native graphics components limit its speed in terms of UI's and graphics-heavy games?
If swing doesn't respond while the application is doing other things that's because of bad programming rather than Java itself being bad. In simple terms, there's a thread called the EDT (event dispatch thread) which should be just used for handling user input, dragging windows around, clicking buttons and so on. Any tasks that take a long time to execute on this thread will block it, stopping any interaction with the interface in question. The correct way to do things is to use a SwingWorker to fire off another thread and notify the UI when it's completed. However, this takes time and extra effort so many people just lazily misuse the EDT, causing the interface to lock up (perhaps indefinitely if the task never finishes.)

In terms of graphics heavy games, Java does actually use native graphics components for these. Libraries such as JOGL are provided with native dll's or so's that are unique to each platform, but a version is provided for each platform. So you still code the same (JOGL handles all the native stuff) and have the application running on Windows, Linux and Mac, but the actual implementation on that machine whilst running will be directly accessing the native graphics components.

Have a look around for JMonkey and some of the games that have been developed using that - Java can certainly be used for this type of work too!
 
Back
Top Bottom