As briefly mentioned in my previous entry, trying anything more fancy than sending a little data over the network, causes JamVM to wildly crash. I've yet not found the reason for this, it only happens for one particular example (that I've come across) and I can't find any obvious cause for it. It happens right after JamVM has actually ended, and the crash is according to Grim Reaper caused by the process of name "", which milliseconds before was named "jamvm.exe". I'm guessing it has something to do with the C-library trying to close/free something that I've already freed, or something like that. One upside of this problem is that I finally got around to sorting out my issues regarding which C-library I'm using.

JamVM currently uses clib2

So, there, I've said it. Its in black and white. I'm using clib2, and I'm sticking to it. I find that I constantly ask myself about design decisions I've made, and wondering both when, and why I came up with a certain solution. I will not use newlib, for the simple reason that I just wrote that "JamVM currently uses clib2". The JNI libraries (java-net, java-io, etc) should preferably use no C-library, or clib2 when needed. Being libraries, we're not using the C-library startup code. Some libraries however dependes on the reference GNU Classpath implementation, which uses c-library functions. So, in some cases it is more convenient to use a C-library.

I'm not entirely one-hundred percent sure that you can mix different c-libraries in your shared libraries, but I really do not see why not. As long as you don't try to make them talk to each other by interchanging implementation specific handles like sockets or such. But I see no reason why one library calling clib2's printf should interfere with another library calling newlib's printf. Steven Solie has a few good pointers on AmigaOS 4 programming in general, and specifically for networking. He also mentions that clib2 is open-source, and therefore a good choice in terms of debugging options. Which I believe it will prove to be, if I don't stumble upon my problem by accident.

What about that colour?

My previously mentioned doodling with mauve (the test suite for JVM's) continues. Instead of hopelessly banging my head against the keyboard, I thought it wise to continue my mauve runnings. With that I might be able to pinpoint the cause of crash more accurately, instead of wading through hierarchies of Java classes. And that is also one step closer to finishing the bounty.

Note to self

Like I said, my memory fails me. So I thought I'd write down how I run mauve. And it isn't that complicated. I have a mauve installation on my DH1, and it's only a matter of putting it in the classpath to be able to run the "Harness" class. However, putting stuff in the classpath should be as easy as setting an environment variable. But clib2's getenv implementation only has a buffer size of 256 bytes, which means that my scattered long windling classpath doesn't fit. Instead of solving the problem, I hardcoded the classpath. Fugly. But it works. Anyhow, with that in place, starting mauve is as easy as:

jamvm.exe -vm=jamvm.exe Harness java.lang.String

The "java.lang.String" reference is the test to actually run. Not entering this will run all tests. Entering something like java.* will run anything in the "java" package.
Edit: Just remembered that you need to say which VM you want to test. If none is specified, it uses "java", which in my particular case will execute the original JAmiga VM, and not JamVM.

Finding bugs as we speak!

Trying to run mauve, and simultaneously writing this blog entry, I'm actually bumping over a bug of "getenv" in java.lang.VMSystem not being linked correctly. How coincidental. Which concludes my rambling for the night. Off to get that bug!