Looking Ahead

Toward the end of 2004, Sun Microsystems is slated to release JDK 1.5. This section discusses some of the publicly announced improvements being implemented into the language and how they may impact game development. Some aspects of the actual language may be slightly different from those presented here, but the core philosophies are not likely to change. Be sure to double-check the information provided in this section against the most current documentation. This information is presented to show how Java continues to grow as a platform and will continue to provide solid resources for game developers. (Also visit the book’s Web page at www.charlesriver.com for updates.)

One important note to make before continuing relates to the technology presented later in this book. Nothing that changes in JDK 1.5 should have any effect on the core game technology as it is presented in this book. This is a considerable strength of the book compared to similar texts. Don’t worry about this book becoming obsolete before it gets back to your development station.

Accurate Native Timers

One of the most consistently mentioned weaknesses of Java has been the lack of a supported high-precision timer. The nanoTimer class is planned for implementation in JDK 1.5 and will hopefully completely remove this concern from Java game development. For more information on timers and the nanoTimer, see Chapter 2, “Fundamentals of Game Programming.”

Generics

The concept of generics comes from one of the problems that has been observed over the lifespan of the language. In the current implementation of Java, games that use collections cannot check the type of object that enters the collection at compile time. Objects that are inserted into the collection must be cast back to the needed type at runtime. The problem with this model comes when someone adds an incorrect object to the collection. The game tries to cast the object as the expected type and throws a ClassCastException when the error is ultimately found. This behavior can certainly be a problem. JDK 1.5 will use the concept of generics to test the type of object being added to a given collection at compile time. This feature also removes the need to explicitly cast the object back while iterating the collection or accessing the data. A quick look at the old style follows:

List l = new LinkedList(); l.add = new Player(); Player p = (Player)l.iterator.next;

The new style of the same code using generics follows:

List<Player:l = new LinkedList<Player:(); l.add(new Player()); Player p = l.iterator.next; 

The new style of code looks much cleaner and allows the program to type-check the information before the game gets out the door. The changes due to generics will not add any additional overhead due to code sizes, making them immediately useful.

Autoboxing

One of the interesting and unique aspects of the Java language is that it maintains two sets of basic types within the language—the standard primitive types, such as int, as well as a group of objects that serves as wrapper classes, such as class Integer. One of the elements lacking in the language is an easy way to convert these types back and forth, especially when they are used with collections. The new autoboxing feature removes this problem and is of particular use to games.

An example of the current way to set and retrieve one these objects follows:

List highScores = new LinkedList(); highScores.add(new Integer(5000)); int score = ((Integer)highScores.get(0).intValue());

With autoboxing this same code is reduced to the following:

List highScores = new LinkedList(); hiScores.add(5000); int score = highScores.get(0);

This code is much cleaner and easier to manage. The autoboxing spec allows for conversions of these types for all similar primitives in the language.

The Enhanced for Loop

JDK 1.5 will also contain a newly enhanced for loop to use with collections. This idea stems from the fact that most iterators are used only to get access to a given element in the collection. Because this practice is common, why not let the compiler take care of the heavy lifting? An example of the current methodology follows:

void render(Collection c) {  for (Iterator I = c.iterators();i.hasNext();)   {     Actor a = (Actor)i.next()     a.render();   } }

The same code using the new for loop follows:

void render(Collection c)   {         for( Object o:c)            ((Actor)o).render();   }

The colon in the for loop is to be read as “in”. Therefore, the loop would be read as “Object o in Collection c”. This feature is a nice addition that should be fairly easy to adopt.

Enumerations

A particularly powerful construct in C/C++ is the enumeration. The enumeration effectively acts as a numeric mask with highly legible values that can be passed through control mechanisms, most notably the switch statement. These types of enumeration are used in games for everything from controlling the current execution state of the game to monitoring various AI states of enemies. The closest thing Java has had in the past has been to implement something like the following code:

public class State     {        private final int currentState;        public State(int state)        {        this.currentState = state;        };        public static final State GAME_PAUSED = new State(1);            public static final State GAME_INIT   = new State(2);         }

Although this code might seem fine to the average Java programmer, the one thing that can’t be done with this class is to pass it through to a switch statement. JDK 1.5 has a solution for this problem.

A new keyword will be added to the JKD 1.5 in the form of the enum. The enum type will contain public, self-typed members for each enum constant. An example of the enum type using the previous State example follows:

public enum State {    GAME_INIT(1), GAME_MAIN(2), GAME_PAUSED(3);    State(int state)       {        this.currentState = state;       }      private final int currentState; }

An example of how this new enum type can be used with a switch statement follows:

Switch(state) {   case State.GAME_INIT: //execute game init method.    Case State.GAME_MAIN: //execute game main method.    Case State.GAME_PAUSED: //pause game   Default: throw new AssertionError("Unknown state" +state); } 

This new type presents a number of new possibilities for control of execution programming and gives a lot more power than the private static int style enumerations of the past.

Static Importing

A problem that many programmers encounter when using constants related to a specific class is the need to fully qualify a constant before using it. For example, if a game needed to use a definition of PI, it would have to properly import the class and then use the value such as the following:

import java.lang.Math; float degrees,radians; degrees = radians *(180.00/Math.PI);

Using the new static importing feature, this same code can be reduced down to the following:

static import java.lang.Math; float degrees,radians; degrees = radians *(180.00/PI);

This might not seem like a massive improvement, but it does make the code much more readable, as well as remove the need to create customized interface classes that contain only constants for the sake of avoiding the default import statement.

These new additions to the Java platform should prove valuable to the continuing efforts of Java game developers. They are indicative of the responsive manner in which Java has been centered on the developer and the growth of the language.