OpenJDK

I have been looking at JDK7 and OpenJDK, and trying to use that instead of the GNU Classpath. The GNU CP will, as I have understood it, not be much further developed. And I believe the only way to go is JDK7, and not stand still at JDk5.

Looking at the CVMI-interface, I found a blog covering the difference between GNU CP and OpenJDK.

Entering monitor and null - treeLock

It seems JAmiga won't initialize static class variables correctly. When synchronizing on getTreeLock of java.awt.Component, treeLock is null. However, creating a simple test class with static initalization in the exact same manner works.

So. Either my newly compiled classpath (just checked out the thing from SVN, since AmiFTP not getting all bits correct [I have to report that], fooled me in believing that my classpath was wrong) has some strange classes (i.e. java.awt. Component) or JAmiga doesn't handle something correct.

Soon - ping!

Ah, yes. Finally, I'm really having some sort of success. I have gotten the java.net stuff in some kind of working state. Now, the work is actually very much on-going, and in progress. It is still trial and error, but I'm really happy to see that JAmiga seldom crashes.

So. Happy. Progress. Fun!

Various progress

The process handling is now in a somewhat more working state. The *nix specific stuff has been removed, and a new VMClass implementation has been created. This basically runs SystemTags() for the command, and on exit tries to send a message to a message port. If the port exists, it means that someone -- the waitFor method of VMClass -- is waiting for the result of the Process. If the port doesn't exists, it is created, and a message is put on queue. Then, with either VMProcess.exitValue(), or VMProcess.finalize() the message port queue is checked (if port exists), the program's return value set, and the message port is removed.

I'm kind of happy with that solution. However, if the SystemTags() is used with the ASYNCH flag enabled, it doesn't return -1 when the command can't be found (i.e. trying to run Mlutiveiw, and not Multiview, return 0 for success), so one can never tell if the command could be started or if the exit code is from the Shell trying to start it. This can perhaps be solved by starting a process that calls SystemTags, with ASYNCH disabled. But I still have to find out a way to know if the SystemTags() succedded... probably by some intrinsic use of wait:s and delay:s... which is not very safe without Forbid() and Permit().

Also, trying with mauve fails. There seems to be something about mauve that likes to create new processes, causing memory failure, which will lead to JAmiga crashing.

Moving to more fun stuff, I tried the AWT classes, which can probably relatively easy be made to work again -- Intuition stuff work, and it seems to be a mere configuration issue initially.

The JAmiga project is continuing...

Process-stuff

The VMProcess implementation in the GNU CP is kind of aimed at *nix-processes using fork and reap and such. The Process.java implementation is relatively easy and actually more coherent with the Amiga-way of handling processes. So, a JAmiga-native VMprocess-class is probably the best route to go. Should lead to fewer internal/extrnal lists for JAmiga-processes, allowing us to use the Amiga processlists directly.

Break through

It seems that my version of the VMCPStringBuilder.class was erronous, or rather; it was probably compiled to have native functionality implemented -- which I haven't bothered with.

So. Progress. I have managed to run a few Process-related stuff, and I'm about to take a look a the Ctrl-C-handling in the Object.wait()-method. This, so any galloping processes (such as my mauve-tries) can be breaked, without JAmiga going down (which is what happens now).

Ping

Yes, JAmiga i s still alive, and work is on-going. Progress is slow, but its atleast some progress.

Now JAmiga "works" with GNU Classpath 0.98. It works kind of like the 0.12 vesion works. There have been work on a few more native methods, but now, mauve has stopped working. Mauve creates new processes for the tests, and the VMProcess methods are... apparently not working correct. A few sockets stuff has been implemented.

All in all, nothing much has seemingly happend, but work is progressing.