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.
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.
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".
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).
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...
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.
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:
This article is courtesy of www.os2ezine.com. You can view it online at http://www.os2ezine.com/20041016/page_2.html.