OS/2 eZine - http://www.os2ezine.com
November 16, 2004
Isaac Leung (P.Eng.) got a degree in Engineering Physics followed by a Master's in Electrical Engineering after which he promptly got a job as a product engineer at a company which makes high speed datacom chips. He is old enough to have cut his computer teeth on Commodore 64's and first played with OS/2 1.3 EE while at a summer job with IBM. The first PC he ever owned came with Windows 95, but he soon slapped on OS/2 Warp 3 and has been Warping ever since. He has agreed to work for Transmeta while he continues plotting to take over the world.
If you have a comment about the content of this article, please feel free to vent in the OS/2 e-Zine discussion forums.

There is also a Printer Friendly version of this page.

Previous Article
Next Article

Injoy Firewall

Golden Code's Java 1.4.1

Recently Golden Code Development released their first "gold" version of Java 1.4.1 for OS/2. Amazingly, there is another version of the 1.4.x implementation for OS/2. This one by InnoTek. However, this time we just take a look at the Golden Code version. Although the first few beta versions were free, the final release is not. Maybe this will help you decide if it is worth it or not.

Why GoldenCode?

InnoTek took the fastest route, by not doing any porting of the Java itself, but rather by using a special runtime piece of software (I don't presume to know how it works, so please bear with me if my terminology is not quite spot on) which enables OS/2 to run the original Java (from Sun implementation of the Windows version). I've been told that this technology is not emulation, not like running it under VirtualPC. It is the same technology they used for OpenOffice and Adobe Acrobat Reader and the rumored Flash 7 implementation. Since the performance of these other softwares is quite a bit faster than under VirtualPC, I'll believe it for now.

The advantage of this approach is that they claim to be able to make the first version much quicker (which they did) and it pretty much guarantees compatibility with the Sun implementation, by design. On the other hand, certain OS/2 users prefer the idea of a "native" version, without the intervention of a translation layer or API or whatever. This is the route that Golden Code chose to take, and obviously they have customers for their approach.

I have to admit, I'm one of those people who prefer the "native" version, perhaps I've been tainted by my experiences with Opera 5 and some of the later versions of Acrobat Reader 4. Regarding Java, I'll readily admit that before I started this, I have no data at this time to say whether the Innotek or Golden Code version is better. I can say that the version from Innotek is free and currently stands at 1.4.2_05, which is pretty much as recent as you can get. The Golden Code version is $42 for a single user license (less for group or volume purchases) and is at version 1.4.1_07. One point for the Golden Code version is that the sound now can be shared and cleans up a lot of problems with certain sound chips. You can read about the new and updated features in more detail.

Getting the package and installing

Acquiring the package from Golden Code was an easy and pleasant experience. It was a more or less "standard" on-line ordering system, and after a very quick registration and approval, I was given access to download the files. You can log in again at a later time to download the files, which turned out to be a very good thing as I crashed my browser halfway through the first time (my fault for running a nightly build and inducing a known bug).

If you don't have broadband, be prepared to wait a very long time. The runtime and development package runs about 36MB. The documentation (which I assume is optional) runs to 33MB and is basically Sun's 1.4.1 documentation. Still, compared to Innotek, where the runtime is 17MB and the development package runs 42MB, it is smaller. (No documentation, but it would be identical the one you can download freely from Sun).

Installation was a breeze, just unuzip into C:\Java141 or whatever directory you choose. The Mozilla plugin (which supports both the GCC and VAC++ builds) is a simple matter of copying the npgcd.dll file into your plugins directory. Just be sure to remove other Java plugins before you use Mozilla, or else strange things will happen. You will also need grab ipluginw.dll and put it in your components directory of Mozilla.

One thing I noticed that greatly impressed me was the detail and clarity of the documentation. Very professional and I can probably guess that they are accustomed to working with large and well-estabilished customers.


First up was just to see how it worked with Mozilla. I previously used IBM's Java 1.3.1 and ever since they switched to the GCC builds and having to use the new ipluginw.dll (coincidence?) I've been having so many stability problems that I removed Java functionality from my browser altogether! However, so far, I've been having very good luck with Golden Code's plug in. It runs fine all day, everyday, and it's probably been a couple of weeks at least by now.

Next up, I tried some of my other applications such as Art of Illusion (I think it now requires Java 1.4), Arachnophilia and others. So far so good! Everything works perfectly. Of course, as I use it more and more, some issues may appear, but in the short time I've had it so far, no big problems. For my final trick, I tried a Java IME for DBCS, specifically, for Chinese. I was especially hopeful since this was on the list of new and improved features. Unfortunately, no such luck. Usually I just plop a copy of the appropriate .jar files into \Java141\jre\lib\ext and that's it. Just click on the window menu and you'll see an extra menu item for "input method". However, it doesn't work for Golden Code's Java. They must be doing something different, because the same trick works fine for IBM 1.3.1 and Innotek's 1.4.2.

Here's one for the rumor mills: You can download a Unicode Input Method Editor from IBM alphaWorks. (You will also need to download ICU4J.JAR). On the web page, It claims to be for Windows 2000, Windows XP and Linux only using IBM JVM 1.4.1 or Sun JVM 1.4.2, but open up the package and go through the readme's and you'll find that it says it supports 1.4.1 only and there is a reference to OS/2 (it's an OS/2 specific configuration tip). If you run the installation, it is not happy with Innotek's 1.4.2, likely due to the version, but it will install happily with Golden Code's 1.4.1. Hmm...either Golden Code is working closely with IBM on this, or IBM has a 1.4.1 JVM for OS/2 in its labs somewhere. I find the former less likely because the Unicode IME doesn't seem to work with Golden Code's JVM! Well, that's just a rumour, read what you will into it! :-)

I also tried a bit of benchmarking to check out the performance relative to other JVM's. The two benchmarks I chose (rather arbitrarily) are the ImageJ Benchmark using the "Fluorescent Cells" image, "Plasma" and "Plasma2" also from ImageJ and Java SciMark 2.0. I ran most benchmarks using both appletviewer where applicable and through the browser (except in the case of IBM 1.4.2 for Windows, as the applet viewer was not available). I also did not run Plasma using the appletviewer for Windows, due to the browser results as you'll see later.

The Plasma tests, I suspect, stress the video quite a bit more than Java itself. The SciMark test runs a suite of math tests which are applicable to many areas in science and engineering (hence the "Sci" in SciMark). For the SciMark test, I also ran a local test (the program is freely downloadable) from the command-line. One version which is "small" and one designed to be too large to fit in cache. Now what I don't have is a benchmark test to check for business or productivity performance. But oh well, this is hardly a rigourous test anyway.

All testing was done on the same machine which dual boots WinXP-SP2 and OS/2 MCP2+fixpacks. It is a Pentium-M 1.6GHz laptop with 512MB RAM and a 64MB FireGL Mobility video card. Tests were run after a fresh re-boot, but no special effort was made to stop all background processes in the interests of being realistic (hey, if you're running Windows, you're gonna need that virus-scan). Windows XP had Norton Antivirus 2002 loaded (but not "active"), OS/2 had ZxMail Server also loaded, but not sending, so we'll call it about even.

OS/2 WinXP
Test IBM 1.1.8 IBM 1.3.1 GC 1.4.1 Innotek 1.4.2 Dual 1.4.x Sun 1.4.2 IBM 1.4.2
ImageJ Benchmark [pixels/sec] 123595 137336 81450 77148 89283 94946
Plasma [fps] 128 / 118 68 / 100 191 / 191 208 470 480
Plasma2 [fps] 56 / 58 64 / 61 76 / 80 78 295 294
SciMark (small)
Composite (overall) 262.51 363.27 181.67 229.44 369.71 220.90 290.79
FFT (1024) 126.28 247.83 85.10 100.93 182.87 86.72 203.48
SOR (100x100) 477.44 491.06 433.60 476.96 907.47 464.77 460.33
Monte Carlo 7.86 60.98 30.24 40.54 69.86 39.41 73.24
Sparse matmult
(N=1000, nz=5000)
315.38 338.25 154.05 218.45 175.92 216.00 263.93
LU (100x100) 385.57 678.25 205.37 310.30 512.454 297.58 452.99
SciMark (large)
Composite (overall) 121.71 110.15 123.41 126.83 259.92 133.49 141.77
FFT (1048576) 12.46 9.49 25.04 20.56 37.55 19.92 22.48
SOR (1000x1000) 319.89 324.36 310.68 316.72 663.06 349.50 344.78
Monte Carlo 7.85 61.03 39.22 40.42 79.55 38.73 74.05
Sparse matmult
(N=100000, nz=1000000)
152.24 146.62 132.71 144.22 285.57 150.36 149.92
LU (1000x1000) 116.10 9.24 109.41 112.23 233.85 108.95 117.61

Please note that this is not a "rigourous" test, and as with most benchmarks, don't take the exact numbers too seriously. It is entirely possible, and likely, that some of this code is not optimized to take advantage of potential gains offered by the latest JVM's and/or the 1.4.x specification is itself "slower".

ImageJ Benchmark

ImageJ has a built-in benchmarking utility. You need to first pick an image to work with, so I chose the "Fluorescent Cell" image, which is part of the ImageJ package (so my results can be easily replicated by others). Now Golden Code itself claims to have benchmarked using this feature of ImageJ, and it's nice to see that their claims basically to add up considering performance vs. Innotek's Java.

IBM's 1.1.8 JVM had a bit of a problem in that the test seemed to complete with no errors, but the image didn't update during the test as it did with the others.

IBM's 1.3.1 JVM (for OS/2) was subjectively the fastest by far, and the numbers prove out that observation, which makes the following result with the Plasma series of tests a bit perplexing. (Actually, reading Golden Code's documentation, they explain why in certain cases, IBM's 1.3.1 JVM is so much faster than others).

Plasma Tests

The Plasma tests are not very computationally intensive, but rather seem to stress the video system. What the number shows is the frames-per-sec [fps] so higher is better. The Plasma test gave less "stable" readings than Plasma2 (which seems to be a bigger version), so any numbers for Plasma within about +/- 20 are probably about equal.

The 2 numbers under most of the OS/2 tests are browser / appletviewer. You can see that using browser or appletviewer doesn't make a difference except for Java 1.3.1 (I checked twice, same result). I'm not sure why.

Windows absolutely crushed OS/2 here. At first I was not surprised, since Windows has much more highly optimized video drivers. On second thought though, this should be a purely 2D test, so I'm not sure why OS/2 should be so far behind. (I'm running SciTech 3.0 drivers). Also, in the previous test, the display during benchmarking was visually much faster under the best OS/2 JVM, while all the 1.4.x series for either platform were about on par with each other. Obviously something funny going on here...

SciMark Tests

As I mentioned previously, this is a set of mathematical computations so it really measures the number crunching abilities of Java here. Of course, that's not to say that the SciMark code could not be more efficient, but it does give a chance to compare all JVM's on equal ground. Higher numbers are better. The numbers shown here are for the local test that I downloaded, though the web and applet numbers are almost identical. The test numbers are highly repeatable from run to run and even from day to day, even with background software loaded.

The first surprise is how well Innotek's implementation compares against Sun's on WinXP. In theory, Innotek's is Sun's (and in fact in the benchmarking, it reports it as such), so it should be at best, equal. I was very shocked to see Innotek coming out consistently faster. So shocked that I ran the tests several more times to be sure (on both WinXP and OS/2). It was the same everytime. With the same Java package, even with the extra overhead of Innotek's runtime, OS/2 came out faster!

A smaller surprise was how well the older JVM's fared. In fact, IBM's Java 1.3.1 was a monster in the small test and easily bested every other comer, including IBM's own 1.4.2 implementation under WinXP. Hence, the poor, dead-last (average score) showing of 1.3.1 in the large test was quite a surprise. Obviously there is some sort of bug creeping in for large tests which don't fit in the cache. If we could only get this fixed...

And the strangest surprise of all? The mysterious OS/2 "Dual" JVM. Normally, you'd expect that if you run the benchmark twice (in parallel), each would perform half as well. And with the same JVM, it does, as I verified under both WinXP and OS/2. However, since OS/2 plays very well with multiple JVM's (I couldn't duplicate this test under WinXP) and since we have two 1.4.x JVM's, this opened up the possibility of running 2 JVM's in parallel. (This was done at late night, hence probably how this strange idea occurred to me).

The very unexpected result of running 2 benchmarks in parallel in the background was that the combined scores crushed almost everything else. Anomaly? Bug? No, I think not. Look carefully at the "small" results. It almost crushed everything else, but not quite IBM's 1.3.1, where it was pretty close for many of the tests. I think this suggests that there is a lot of room for improvement for the OS/2 1.4.x series of JVM's, at least when it comes to my Pentium-M CPU. (I also found out later that Golden Code supports simultaneous, independent running of their JVM).

It also begs the question: "Why is OS/2 so much faster?". It is hard to imagine that IBM did not carry over knowledge from 1.3.1 OS/2 to 1.4.2 Windows, so it wouldn't be unreasonable to assume that the relatively poor showing under Windows is a Windows specific problem. On top of that, the "dual JVM" test shows what OS/2 is capable of and that the previous performance attained by IBM's 1.3.1 is not necessarily a result of a change in performance going from 1.3.x to 1.4.x.

Memory Usage

My informal memory usage test merely consisted of loading up Art of Illusion 1.9 and checking the RAM usage with Theseus. Here Golden Code showed up as using 50MB for Java while Innotek chewed up only 32MB. And it wasn't as if Innotek spawned off another process to do its thing somewhere, as the total system free memory showed the same difference.

I also took a quick look using the memory monitor under ImageJ. IBM's 1.1.8 JVM came out just smaller than Golden Code's JVM, with the rest of them a little bit higher, but mostly approximately equal. One thing that I noticed was that OS/2 seems to be more "aggressive" at periodically freeing up memory than the Windows (and Innotek) versions, though keep in mind this is a very non-rigourous and unscientific test at this point.


Well I think we have seen that the Golden Code Java 1.4.1 package is a very reasonable performer when stacked up against other 1.4.x implementations on Windows or OS/2. However, there are still some improvements to be had, relative to some of the Windows implementations, and also IBM's old 1.3.1 JVM.

On the other hand, it is so far proven to be very stable. It is well-documented and easy to install. Only extended testing will show if it is more stable than Innotek's implementation and if there are any bugs than show up on one JVM and not the other.

While I did purchase Golden Code's 1.4.1 package, I think given the above information and my limited experience with the Innotek JVM, it is not easy to recommend it at this point to the average user. (Although I have no regrets about purchasing it). $42 is hard to compete with $0, especially when the Innotek JVM provides most of the functionality and is pretty close in performance if you have a fast machine. Some tests were faster and some were slower.

However, let this be a guide only, take a close look at the features of both and see if one fits your need better than the other. There may be some finer differences between the two that will make the choice for you. If you absolutely require 1.4.2, then you must go with Innotek. Otherwise, Golden Code has the following unique features:

  • Great documentation. All features and even known bugs and limitations are documented. Benchmarks were performed vs. IBM 1.3.1 and Innotek and it goes into great detail about how the tests were run and analysis into the performance differences. (For me, the documentation and thoroughness of testing is nearly enough to justify the $42 spent).
  • Sound card sharing
  • Supports LIBPATHSTRICT which enables you to run multiple, separate JVM's simultaneously
  • Supports SMP, which can be handy if you run two simultaneous JVM's.
  • Can use on old Warp 4 system (pre-FP13).
  • Can install on pre-Pentium machine.
  • Input Method fully implemented (I can't get this working, so I'll be contacting tech. support to see what's up) and works with DBCS.
  • Drag 'n drop support between native OS/2 and Java (I have to find a Java application which supports this first)
  • Various debug and development enhancements specific to OS/2
If features don't decide it for you, then whenever possible, you should always do your own benchmarking on the real applications you intend to use to see which one performs better in the real world. (I'd be happy to test your app for you, if you don't have access to the Golden Code JVM). Either way, it's great that OS/2'ers have a choice and it's nice to see the performance potential of OS/2 as a Java platform vs. WinXP.

Previous Article
Next Article

Copyright (C) 2004. All Rights Reserved.