Given it has mainly been compiled on PPC version of Linux, I guess it might be easier to port than some x86 Java VMs.
Quote:
JamVMs interpreter is highly optimised, incorporating many state-of-the-art techniques such as stack-caching and direct-threading. The latest version of JamVM extends this to include a code-copying JIT compiler (also known as super-instructions). The performance is on par with a simple JIT, while retaining portability. As most of the code is written in C JamVM is easy to port to new architectures. So far, JamVM supports and has been tested on the following OS/architectures :
Linux
* PowerPC: for many years my main platform, so this is well tested. Built and tested on G3 and G4 systems. (snip)
The VM isn't the problem. The class libraries are, and what we need there is OS-specific. This is the part that takes forever.
P.S. Nothing for Jamiga is being ported from "x86". The jamiga VM is new from scratch. The class libraries are being ported from Gnu Classpath (GPL, not sure if it's Linux-only or not) or later OpenJDK's class libraries. Those are OS-Specific translations from Java to your own OS, so when a java program wants to open a window or write a file or print some text, it has to call your OS (ie. Reaction, MUI, dos.library, whatever) and the class libraries do this stuff. It doesn't matter which class library you port from, they're all foreign to AmigaOS, so it all needs redone regardless. I don't know that Linux is easier than Windows, and I'm not sure you'd see a difference between PPC and x86 there. Maybe endianness of something, but since it all readlly needs ripped out and started over anyway, doesn't make a big obstacle.
I looked at JamVM, and got it to compile, but never run.
As billt says, most work is needed for the classpath-libraries. So, at least in theory, it would be possible to use the same classpath for both JamVM and JAmiga.
Given that JAmiga works today, I have chosen not to put more effort in JamVM, but instead focus on the classpath stuff. Currently this is GNU Classpath, but I am looking at OpenJDK aswell, and for new stuff I try to use the same approach as they have in OpenJDK. The GNU Classpath is said to be abandoned, since we now have the OpenJDK.
The VM isn't the problem. The class libraries are, and what we need there is OS-specific. This is the part that takes forever.
P.S. Nothing for Jamiga is being ported from "x86"
I understand, but I do not think you are entirely correct: Our existing Java VM(s) are entirely interpreted, where-as this is (supposedly) a super-fast one which now even approaches JIT speed... while still being portable. JIT means x86 would be a major rework, but this is already PPC friendly.
Seems to me it *might* make more sense to put effort into writing class libraries for a portable & fast VM, where many people keep the VM up-to-date, rather than have class libraries running on an Amiga-only VM for (what might eventually become) an ancient version of Java?
OTOH, maybe it would be better to spend effort on (class libraries for) our existing VM, and get "some" result, rather than 'waste' some (alot?) of it porting them a different VM, and end-up never finishing...
ChrisH wrote: @billt Seems to me it *might* make more sense to put effort into writing class libraries for a portable & fast VM, where many people keep the VM up-to-date, rather than have class libraries running on an Amiga-only VM for (what might eventually become) an ancient version of Java?
OTOH, maybe it would be better to spend effort on (class libraries for) our existing VM, and get "some" result, rather than 'waste' some (alot?) of it porting them a different VM, and end-up never finishing...
The class libraries should work with whatever VM we have, interpreted, JIT, this, that, whatever.
If I understand you suggestion (and i now don't think i did)to somehow use some more general class libraries that can be common to different OSes, and thus combine resources with them, that's an interesting idea. I'm not sure how practical it is, as I don't know that Java targets such a thing. it might be interesting to port Java to wxWidgets, as wxWidgets is a cross-platform API enveloping most of what you'd do (GUI, GL, network, file access, etc) and also look native to whatever OS you're using, rather than QT apps always looking like QT no matter what OS you're using. But we'd have to do such a thing and get other people interested in it for resource combining with them. And this would be a little slower performance than OS4 native class libraries due to yet another wrapper in between.
And we'd need wxWidgets or whatever common API to target completed on AmigaOS first. Which common APIs are completed to that level here? Maybe some via AmiCygnix, maybe QT. I'm not sure how far QT goes with things Java would want to call, or how complete it is at this point on all aspects.
As stated, classpath work has to be done anyway, irrelevant of VM used. Both JAmiga and JamVM uses GNU Classpath. JamVM also has support for OpenJDK, and new stuff in JAmiga classpath aims at being OpenJDK "compatible". Either way, the actual work can be re-used, if not used right away.
Regarding QT and other APIs, those are possible. One GUI toolkit in GNU Classpath uses QT. But, given that some GUI toolkit functionality is already implemented in JAmiga in Gadtools, it is actually easier to work with that. And I personally would like Java on Amiga to be truly Amiga. We're discussing on implementing a MUI toolkit, since that allows us to use it with AmigaOS4, OS3, Aros and MorphOS.
And I personally would like Java on Amiga to be truly Amiga. We're discussing on implementing a MUI toolkit, since that allows us to use it with AmigaOS4, OS3, Aros and MorphOS.
I can agree with that and/or Reaction being the best goal for jAmiga. I think I misunderstood the other poster's suggestion, wrote my post about wx and QT et al, then looked at his post again and realized I think I had understood him wrong. But left my post anyway. :p The more layers there are, the slower it will go, and I think we'd all like as much speed as we can get.