It's time to have some fun with this stuff! (Scott McNealy, JavaOne keynote)
For all of it's penetration as the language of the web, the server, and other applications, Java has made almost no inroads on the gaming community. Apparently, McNealy would like to see that change.
From Java-enabled golf clubs to Java-enabled Dreamcast systems, the next target for Java appears to be entertainment. Even, the popular "Who Wants to be a Millionaire?" computer game runs under Java. The next big push for Java is clearly gaming, and hence, it's time for OGS to start paying attention.
Welcome to this, the first issue of JOGS: Java Open Game Source, a somewhat frequent look into Java, open source, and gaming. We'll start looking at Java gaming products in our next article, but I thought we could start this out with a look at how these three diverse items combine together, where they are going, and what we can do to help direct their course. I've just returned to 5th annual JavaOne in San Francisco, so I'll also bring you some feedback from there.
Modern Java virtual machines, such as those by Sun and IBM, are much better than they have been in the past. Previously, a Java Virtual Machine was primarily an emulator. Soon, however, some JVMs began compiling the Java code to native code as a part of the startup process. However, modern virtual machines do something which C/C++ usually does not: dynamic compilation and optimization. HotSpot, Sun's current JVM, does some pre-compilation, but also profiles your code at runtime. This allows it to figure out the most important areas to optimize, and then to make the optimizations as your program runs. In addition, HotSpot includes a new garbage collector without the annoying tendency of its ancestors to bring your application to a halt. HotSpot is available with Sun's JDK 1.3 for all platforms. These changes have overcome many of Java technology's performance issues, and provide a much better platform for building applications.
Ok, so Java is not quite ready to run Quake II. However, not all games are first person shooters. There is no reason a turn based game such as Civilization could not run perfectly fine under Java on reasonable (Pentium or above) hardware. Even a game such as TrollBridge (overhead step-scroller) could easily run under Java 2.
The other key to achieving reasonable graphics performance was the advent of much better drawing algorithms under Swing, which became standard in Java 1.2, aka Java 2. Modern Java applications should be constructed using Swing exclusively.
During JavaOne, several techniques for optimizing code were presented. Many of these involve performing the same sort of routine tricks that were common before the world became the sole bastion of optimizing compilers. For example, the following loop could easily be made more efficient:
public class Silly
{
public static final int ARRAY_LENGTH = 32;
private char[] char_array = new char[ARRAY_LENGTH];
public int sillyMethod ()
{
for (int count = 0; count < char_array.length; count++)
System.out.println(char_array[count]);
return;
}
}
Aside from being a pointless piece of code, the above shows two possible performance problems with Java code. First, since Java is multi-threaded, the compiler cannot assume that the variable char_array has not been altered between bodies of the loop. This means that even though it is reasonably obvious that the size of the character array has not changed from this piece of code, the length must still be checked each pass through the loop. So, we could rewrite the code as follows:
public class Silly
{
// ...
public void sillyMethod ()
{
int len = char_array.length;
for (int count = 0; count < len; count++)
System.out.println(char_array[count]);
return;
}
}
In fact, however, there is still one more optimization we can make. On most platforms,
it is much faster to compare a variable against zero than against some arbitrary value.
The reasoning behind this is that at the machine code level, on some platforms (PowerPC
of note), the code to compare count against len consists of
subtracting the two and comparing the difference against zero.
public class Silly
{
// ...
public void sillyMethod ()
{
int len = char_array.length;
for (int count = len; count > 0; count--)
System.out.println(char_array[count-1]); // Different output, but only for example
}
}
The above code prints the array in reverse order, which is probably not what we wanted, but for a more realistic example where we might be adding the values in an array, etc., this is a real optimization. These and other techniques were discussed during technical sessions at JavaOne.
In most circumstances, this kind of detailed optimizing will not help. However, if
the profiler tells you that sillyMethod is hogging 20% of your CPU time, then
perhaps it might be a good idea. Always profile your code!
Regardless, as JVM's become more advanced, they will behave more like C or Fortran optimizing compilers, and we will not need to make these kind of alterations. Keep in mind that Java is only 5 years old. Much less time has been spent making it fast. However, for most tasks, it is more than ready.
The open source world and the Java world don't often overlap. (overheard at JavaOne)
Well, maybe not. Frequently, many of those who work in Java typically come from more of a business background, or have only used Java recently in College. Open source has a tendency of attracting old school UNIX hackers, and others who enjoy working with the details of coding. Java in many ways tries to hide the subtle points of writing code, such as memory management (you have garbage collection, instead), detailed performance control (all functions are virtual, no inline, etc.). This presents something of a culture clash.
However, Java has some pretty tempting things to offer: built in support for threads in the language, in a clean and consistent way; multiple-language support; network support; etc. Many of these are truly arcane points of programming under C/C++ or other languages, and at best are difficult to get right. With Java, everyone can quickly be writing multi-threaded code, key for complex programs, including games.
However, there is open source work in Java. While it does not dominate either open source or Java, there is plenty out there. Part of the issue, however, is the somewhat closed GNU mind set, which will not accept any software unless it was produced and executes with other open source software. Sun's JVM and compilers do not fit this mold, and the open source clean room implementations (such as Kaffee, gcc) are not quite ready for prime time. It is perfectly possible, however, that these could come to dominate the market, if sufficient effort was expended upon their development.
Kenneth Flynn is a computer programmer for the Naval Research Laboratory in DC, where unlike his many counterparts, he does not build bombs for food. He is also an astronomy graduate student at the University of Maryland, where he wishes he had some food. He is also an independent consultant, where he occasionally watches food grow moldy. He was also, unfortunately, the roommate of Dennis for most of his undergraduate days. That might explain this bio. Kenn specializes in Java development, with a bit of C++ on the side. He can be reached at flynnk@astro.umd.edu.