Do you think that Java has become a little staid and unexciting? As a language matures and your experience with it grows, does it not naturally become less interesting? Well, that's what I tend to tell myself.
I have a theory about what really sells a language -- that is, for those developers who are lucky enough to choose the paradigm they work in. My theory -- completely unscientific, of course -- is that developers base their decisions on two simple factors:
- The coolness factor
- The "what's-in-it-for-me" factor -- in other words, how many jobs will it generate, what kind of work will I do, what sort of career path does it offer and, most importantly, what is the likely salary?
In Java's early days, the applet drew developers to the emerging language. When I read about Java in a magazine article in 1996, I was interested, but it was not until I saw my first applet that I became hooked on the idea -- the coolness factor clearly at work.
Since then, other client-side Web technologies have grown popular -- without completely replacing Java in the browser -- and consequently, developers now choose a language for what's-in-it-for-me reasons. As the demand increases for Java developers, salaries continue to head skyward.
Eventually the coolness factor cooled, as did general excitement for the language, until Java 2 Micro Edition (J2ME) came along.
Smaller is better?
If you believe industry analysts, who sometimes rival movie critics in their accuracy, embedded computer usage will grow by enormous percentages over the next three to five years. Mobile phones and PDAs are just the tip of the iceberg. Home networking, wearable computers, and more hover in our near future. What better platform to power the applications on those new devices than Java?
All the reasons for using Java on the desktop and server apply to smaller machines as well, and the most important reason, of course, is platform independence. With the possible exception of Palm, no single operating system rules the world of embedded devices at the moment, at least not compared to the desktop world. Some argue that portability is not an issue for embedded devices; speed and stability take precedence. While it may not be essential to operating system or hardware manufacturers -- who, after all, want more products for their systems than are available for their competitors -- I believe portability remains a concern for developers. The more market you have, the more money you can make.
The killer app
So what will be the first killer applications for cutting-edge mobile phones that sport color screens and broadband Internet connectivity? The answer: games. What sort of games? Answering that question exposes a slight inadequacy with J2ME: as opposed to the original Java killer app, the applet, it's difficult to demonstrate J2ME's potential and thus difficult to demonstrate J2ME's coolness.
To see an applet in action, you just launch a Web browser and point it in the right direction. But because of the lack of real hardware available for developers to experiment with, demonstrating a MIDlet (an application written for devices supporting the Mobile Information Device Profile) on a mobile phone is a difficult proposition, particularly outside the United States and Japan. Worse yet, a mobile phone CPU may run at less than 20 MHz, a Palm Pilot at 16 MHz to 20 MHz, and a high-powered color PDA at 200 MHz. Mobile computers such as Cell Computing's Plug-N-Run Modules can run at 500 MHz and over.
You could feasibly use all of those devices to deploy J2ME applications. But which processor speed do you develop for? Which market is likely to be the largest? Some of those devices are popular now, but which will be popular in the next few years?
The proliferation of emerging devices and those devices currently in development exacerbate the problem even further. And don't forget the growing number of companies developing Java on the metal -- running Java bytecode directly on the CPU -- which promises an increase in speed and perhaps entices more consumer electronics manufacturers and their products into this ever-expanding device market. ARM is one such company that has recently announced Java support on its processors (see Resources for more information).
Even putting aside those technical considerations, a final -- and arguably fundamental -- complication for the moment is that you cannot describe the technology as approachable with respect to the nontechnical public at large. That is, until John Q. Public is able to wander down to the local electronics store, pick up a mobile phone or PDA with Java already built in, and try out the technology without having to download or install anything.
Ultimately, if you have faith that those issues will sort themselves out as the technology matures -- look at the features and performance improvements of the standard JVM to realize that it will take a while to iron out any wrinkles in J2ME -- your choice of game type will depend on what approximate processor speed you decide on. For example, if you target mobile phones, the games will be simpler, as will the graphics. However, those games that will really make an impact will be graphic intensive. Imagine a massive multiplayer role-playing game (RPG) with basic 3-D graphics, running on a PDA. While it is not exactly the most original idea, it is a suitable example and a good starting point for this discussion. The big question: Can you build that type of game with Java?
MIDP or PersonalJava: The battle of the midgets
The two major players in J2ME at the moment are the Mobile Information Device Profile (MIDP) and PersonalJava. Does one or both of these provide the facilities and performance required to develop a 3-D game?
The MIDP is at the bottom end of the ladder: a redesigned version of Java intended to run on the simplest devices. Because of its limited processor speed, limited memory, and low resolution, you are restricted in what you can do with the MIDP. 3-D is entirely possible on MIDP devices; for example, vector graphics can use the standard Java graphics primitives, such as line and polygon drawing, to produce 3-D shapes. However, the lack of ability to directly blit -- copy raw pixel data -- to the screen from a pixel buffer, for example, makes life rather difficult for anything more advanced, such as particle effects or simple texture-mapping (see sidebar, How Not to Blit).
So if not MIDP, what about PersonalJava? PersonalJava has been around much longer than MIDP and supports a larger subset of the standard JDK, which means that working with raw pixel data is quite simple. In addition, specifications have been accepted for development in the Java Community Process that more tightly integrate PersonalJava into the J2ME framework: the PDA Profile for J2ME and the Personal Profile Specification.
The PDA Profile describes "...a standard platform for small, resource-limited, handheld mobile information devices..." (from JSR #000075 PDA Profile for J2ME). In hardware terms, that means a memory capacity from 512 KB to 16 MB, and "...a resolution of at least 20,000 pixels" (see Resources for more information).
The Personal Profile defines its targets as having a minimum of 2.5 MB ROM, 1 MB of RAM, network connectivity, and the ability to run applets. In addition, it "will also provide a smooth transition for those utilizing already-existing versions of PersonalJava technology" (from JSR #000062 Personal Profile Specification). Once products emerge based on those two profiles, PersonalJava as we know it now will begin to move into the mainstream of J2ME.
Moore's Law and the game development life cycle
One of the more quotable theories in the information age, Moore's Law states that processor power will almost double every 18 months. At its present pace, the computer industry exceeds that estimate.
Currently, the low end of the processor scale for PDAs averages around 20 MHz, like the Palm IIIc. The higher end would compare to the soon-to-be-released Yopy -- with a Linux-based operating system -- which has a 206 MHz processor, or Compaq's iPaq, which also has a 206 MHz processor. Thus, according to Moore's Law, you could expect high-end PDAs on the market in 18 months to have a processor speed of around 400 MHz, which is in line with the laptops and even desktops that many people currently use.
With large development teams, it can take anywhere from 12 to 36 months to develop PC and console games. Some of the more complicated games are pushing that upper end of the scale; however, you would expect a game for a PDA or mobile device to be at the bottom end.
Possibly then, a good rule-of-thumb in constructing a J2ME game would be to aim for the processor speed expected at the end of the estimated development time.
My imaginary friends
Back to the original question of feasibility. In the tradition of 8-year-olds all over the world, I have invented an imaginary team of experienced Java developers. I estimate that my team can complete development of my revolutionary multiplayer 3-D RPG in about 15 months, with the target platform being high-end PDAs. Being a tad conservative, I am unwilling to take Moore's Law entirely at face value, so I'll anticipate that by development's end, processors between 280 MHz and 320 MHz will be available. Luckily, despite the absence of devices on which to test, it is still easy enough to buy laptops with approximately that range of processor power; my team can test on those. In addition, an iPaq running PersonalJava will hopefully provide an adequate platform for compatibility and below-baseline performance tests.
The screen real estate available on PDAs differs from machine to machine, so the game engine will have to be scalable depending on processor performance and screen resolution. A good minimum size would be equivalent to Nintendo's Gameboy Advance, which has a 240-by-160 pixel display.
The next step is to find out whether the intended CPU range, coupled with the minimum display resolution, will be enough to provide a reasonable frame rate for 3-D graphics.
To determine a possible frame rate -- without writing a 3-D engine to play with -- the simplest test is to calculate how long it takes to dump a random array of pixels to the screen X number of times.
Java provides a number of ways to convert raw image bytes to an image. The most common is to use a
MemoryImageSource along with a
PixelGrabber to obtain the pixels from any image with which you want to start. After that, it is fairly simple to manipulate the bytes and refresh the display for animation.
However, I have found that the most efficient approach is to implement the
ImageProducer interface and set the image's pixels directly. That eliminates one or two steps in the
MemoryImageSource option and seems to be about 10 percent to 20 percent faster on average.
For my test, I modified an applet developed as part of the TinyPTC framework (see Resources for more information). The new applet,
BlitTest, displays a test pattern and calculates the number of frames per second (fps), based on the amount of time required to deliver 500 frames of animation. (Thanks to the guys at Gaffer.org for allowing me to use their code.)
The following figure is what you will see when running the test applet -- what looks roughly like TV static.
The projected frame-rate figure will not directly correlate with the frame rate on the final 3-D engine, which, after all, has not even been written. That is because most 3-D projects probably have a number of loops and inner loops, whereas
BlitTest contains only a single loop, but it offers the highest performance available. From there, we can estimate the probable engine performance.
You can try the test applet out here: BlitTest. Please note that this is not a nice applet; there is no
Thread.sleep() on the graphics loop, which means it will eat up any available CPU resource. In other words, it will use 100 percent of the processor on some machines. So use it at your own risk.
Running on a high-end machine, such as a dual-processor Pentium III 800 MHz using a JDK 1.1 appletviewer, the test runs in just 1.36 seconds. It provides over 367 frames per second, which is more than enough processor power to do whatever we could want. (Although that test applet is not meant to be a performance benchmark of JVMs, as a matter of interest, the appletviewer for JDK 1.3 performs the worst at 275 frames per second, while Internet Explorer 4's VM performs the best at 400 frames per second.) Unfortunately, we are unlikely to see a PDA on the market offering that sort of performance for a number of years.