Java programming and the Amiga, an overview (Part 2)

In 2024, should we use the Java programming language on the Amiga?

Welcome back! In the previous post, I presented a short description and history of both the Amiga computer and the Java programming language. I also highlighted Some of their strengths and weaknesses. I finally introduced a summary of the different Amiga JREs.

The following question was raised: How useful is Java on the Amiga in 2024? This question has a follow-up one, how potentially useful could Java be on/to the Amiga?

I'll answer the first one by testing the performance of different Amiga JREs easily available today. I'll try to answer the second one based on our newly learned experience with these JREs and our research findings.

But first, some precisions and corrections. In the first part, I listed the different JREs as working implementation on 05/05/2024. The actual latest version of Kaffe still readily available for the Amiga is v0.7.1, which does not fully support JDK 1.0 nor does it have a JIT JVM.

The initial confusion comes from the FAQ text file in the last snapshot of the Kaffe code repository.  In April 2003, Tony Wyatt stated that he successfully built v1.0.7 on his A4000. Unfortunately, I was unable to repeat his result. I suspect that this failure is caused by a different build environment and toolchain. He did not provide all the information to recreate his build.

Kaffe does have a JIT JVM for the 68K processor but it is only available for Linux or *BSD operating systems. The use of processor trap exceptions and additional signal usage for inter-process or thread communication might make its implementation on AmigaOS difficult.

JAmiga v0.0.5 does not provide a JIT JVM. It was in the works but there's evidence in the source code that it was removed from that latest version.

Something that I didn't mention before is that Java could help (re)unify the whole Amiga community. Since the mid-nineties, multiple "flavours" of Amiga attempted to bring the ageing AmigaOS 3 into the next millennium. AmigaOS 4, MorphOS, AROS, and pOS are all "next-gen" Amigas. But, of course..., each one of them is incompatible with the other. With Java, one Amiga developer could create a single application that would run on all flavours. No need to put more effort into adapting the source code for each flavour.

Test setup

I created the test environments using WinUAE v5.3.0. WinUAE is the Windows version of the (Un)Usable Amiga Emulator. It first appeared in 1996 but was very limited. The Amiga is a difficult machine to emulate because of the multiple co-processors and DMA channels of its architecture. Initially, only the most simple application or game that didn't rely on specific hardware behaviour would run. Even when an application ran, it was slow on the PC hardware available at the time. Version v1.0 of WinUAE appeared in 2005. By that time, compatibility had improved and speed was usable thanks to a JIT 68K emulation. Version v3.0.0 introduced in 2015 brought PowerPC hardware emulation and the possibility to run the latest version of the Amiga operating system, AmigaOS 4.1. Today, v5.3.0 emulates most hardware available out there, and some more.

About the test conditions, the AmigaOS v3.1 test environment simulated an Amiga 4000 with an M68030 processor, an M68882 Floating point unit, a CyberVision 64/3D graphics card, and 64 megabytes of RAM.

The second test environment used the "Final Classic" version of AmigaOS v4.1. An A4000 with a CyberstormPPC accelerator (M68060 and PPC 604e processors), a PicassoIV graphics card, and 128 megabytes of RAM. I encountered some difficulties when installing AmigaOS4 on the emulated A4000. The system would boot fine from the install CD and the installation would carry on all the way to the end. But when rebooting for the first time after the installation, the system would hang or crash. I fixed this problem by carefully reading the hard disk preparation section of the installation FAQ available on the install CD, and then making sure that the FastFileSystem and SmartFileSystem were correctly installed onto the RigidDiskBlock.

Both these environments used WinUAE JIT processor emulation. Both were running on the same hardware, a Lenovo laptop with an Intel i5-4200M processor with a base frequency of 2.5GHz (max. 3.1GHz) and 8GB of RAM. I had Windows 10 Pro 22h2 as the host OS.

I ran all the tests at least 4 times in a row. The presented results are from the last 3 runs of the test. I observed very little variations between each run, except for the very first run. I expected that particular variation, as it is often observed when using any caching mechanism. WinUAE JIT processor emulation does use cache.

All test source code was compiled using the Jikes compiler version v1.18. The classes used for compilation were from the JAmiga v0.5 archive. These classes are from the GNU Classpath project version v0.12. These are functionally equivalent to those of the JDK v1.0.

Results

The Sieves test is the Sieves of Eratosthenes algorithm, which finds all the prime numbers up to 3,000.

The Bubble test is a Bubble sort of a randomized array of 1,000 32bit integers.

The Merge test is a Merge sort of a randomized array of 1,000 32bit integers.

Results are in milliseconds, the smaller the better.

Results on AmigaOS 3

*Note: JAmiga results for Bubble sort were wrong. (The array was not sorted)

Results on AmigaOS 4

I used Kaffe on both 68K and PPC environments to assess the speed differences between the two emulated environments. Keep in mind that Kaffe is running in AOS4 68K emulator.

jBYTEmark Results

jBYTEmark v0.9 came from BYTE magazine. They ported their C BYTEmark benchmark to Java in 1996. It is a more comprehensive benchmark than the simple sort algorithms of the previous tests. Unfortunately, Kaffe v0.7.1 can't run it due to a bug.

An index value of 1.0 is the baseline speed of Symatec's Cafe v1.0 JRE on a Pentium 90MHz, greater is better.

Interpreting the Results

Choosing which JRE to use depends on which version of AmigaOS is used. Under AmigaOS 3, Kaffe is the clear winner over JAmiga v0.5. Not only it is the fastest but it also outputs the correct result. Under AmigaOS 4, JAmiga2 may not be the fastest in every test but it is significantly faster when it is. This result also means that there is still room left for improvement to bring its Sieves performance on par with the other tests against Kaffe.

I conducted the jBYTEmark tests to see what is the performance penalty of having a JVM without a JIT. In this test, an improvement of 20 times can be seen for OpenJDK. This improvement is interesting, knowing that the Amiga JVMs don't have JIT implementations and the performance could be drastically improved.

Disappeared Artefacts

During these experiments, I stumbled across multiple documents describing pieces of software that I couldn't find. The servers hosting this software were either put offline, had a hard disk crash without a proper backup, or the pages and their contents had been removed. I tried retrieving them using the Wayback Machine without success.

It seems that a more recent version of Kaffe was available for the Amiga at least as source code. The source code would have been in a different snapshot of the Geek Gadgets repository than the one available on the Internet Archive.

It also looks like that an attempt at bringing the Abstract Window Toolkit (AWT) to the Amiga was underway. AmiAWT was mentioned (in AMIGA-Magazin 12/1998) to be in a Beta stage. These classes were supposed to be available on the project Web site. No copy of it could be found yet. If available and in a somewhat usable state, some Java applications with a GUI could potentially run.

It was also mentioned by the author of the commercial Daytona JRE that some work was already done. Back then, he was looking for someone to take over the project. Maybe the source could be retrieved and released to the community. Maybe some of that work could be salvaged and used in other Amiga JREs. The same could also be true for the other abandoned projects.

Future Developments

Now that the flaws of the currently available JREs have been exposed, what could be done about it?

I'm confident that the missing source code for a later version of Kaffe could be found and built. That finding would unlock the possibility of using JDK v1.4 or v1.5 and hopefully fix the bug encountered when trying jBYTEmark.

The same could happen with AmiAWT. It could be updated (if need be) to work with a newer version of Kaffe, increasing compatibility. It may be possible to improve it to allow using Swing, which would in turn allow more Java graphical applications to run.

The best overall JRE is currently JAmiga2 on AmigaOS4. Because it is only available on that Amiga "flavour", I believe that it seriously reduces its usage. It seems that most of the active Amiga community is using original 68K hardware or clones. The most recent replacement hardware developments are focused towards the original 68K. Many of the 68K hardware clones that are now available are also much faster than the hardware that they replace. I think that porting JAmiga2 to AmigaOS 3 should be attempted.

It's difficult to estimate how much work these improvements represent without first seeing the missing source code. One certain thing is that Java is still relevant, alive and well after all these years. There's no sign for this to change. Even if the required work to update the Amiga JREs takes years, it would still be useful.

Conclusion

I discussed the two test environments possible thanks to the WinUAE emulator. I also explained the performance and drawbacks of the three Amiga JREs available today for AmigaOS 3 and 4. I speculated on what the current status of the JREs could be if the software that is currently lost, resurfaced again.

In 2024, for anybody looking at using or developing with Java on the Amiga, the only solution that could work "out of the box" is JAmiga2. The lack of AWT or Swing classes used to create a graphical user interface is a serious limitation. Amiga users are expecting a GUI for their applications. The lack of AWT limits the ease of use and usage for new software projects. Until AWT gets implemented, we can't hope for the Java language to become popular and fulfil its promises on the Amiga.