Change the channel, trip the station

GNU Classpath is very Unix-centered. This has some impact on the java-net implementation, since Unix treats kind of everything like a file -- AmigaOS does not. This means that gnu.java.net.PlainSocketImpl uses VMChannel's read() and write() methods, which calls AmigaOS functions read() and write(). These functions expects the fileDescriptor to point to a file, not a socket. So I have to make some modifications to the VMChannel, adding socket specific read and write methods. Also I have to make sure not to close any sockets using file closing functions.

Given the big difference between a socket and a file in the Amiga world its really tempting to make a completely new VMChannel only for Sockets.

Bugs found and fixed, networking in progress

Working on JAmiga's network support I discovered a bug in the class loading. An object of an class extending an abstract class, which in turn implements an interface, couldn't find the interface's methods. It took my quite some time to find that the class didn't search the extended class' interface, but only its directly implemented interfaces. Anyho

w, the fix was easy. So that's yet one bug down.

I have also put some time into debugging and tracing, both removing irrelevant stuff, and making some output conditional, using the -verbose argument.

More interesting though, is that I will have some sort of networking working soon. I've been re-thinking and trying some different approaches, and finally found something that will be stable, and hopefully not too slow. It's a solution where each Java socket actually has a dedicated Amiga process. This Amiga process shares the socket-library base with all other sockets which in turn is opened by a global javanet process. Whenever a new ServerSocket(80), new Socket("localhost", 80) or a socket.accept() is called, the executing process sends a message to the global javanet process which starts a new socket process and returns an ID to the process. Subsequent calls on that socket is then made directly to the socket process.

The reason for having this solution is that the socket-library base needs to be shared between all sockets -- one socket cannot use one socket-library base to send data, and one library base to receive data. Since we might have several Java threads (one Java thread maps to one Amiga process) sending the poor Socket object from and to each other and doing all kinds of stuff to it, there must be one process for each socket. It is also not possible to have one process for all sockets created by one VM. One VM may start several threads that are supposed to communicate using sockets. Imagine one thread waiting to accept incoming connections, and the other thread wanting to connect. Thread one has its socket waiting in the global socket process, and the other thread... well... has to wait for the socket process to accept the connection, which waits for the other thread, which waits for the socket process...

The downside to this approach if of course the messages having to be sent to and from the processes. But AmigaOS is pretty darn good at IPC. So I don't think its a problem

One issue down...

Ok, not a biggie, but still progress. I have implemented the setting of properties from commandline. It was neither complicated nor very fun, but it was needed.

Fig 1. This screenshot shows us jamiga running the TestProperties-class (its source code is visible in the Cubic window to the right), with the parameter -D which sets a Java property.

I am in the process of finalizing the network support. However, something is going wrong so I need to do some debugging. To simplify the debugging process (so I don't have to recompile when a new class shouls be debugged), I am implementing the java commandline options for verbose output (-verbose:class), with added possibility to enable it for a defined set of classes, using -- you guessed it -- the "-D" parameter.
In the screenshot you can also see JAmiga starting the network process -- or rather, you can see JAmiga checking if the network process is started, which it is after the second try. If you'd be able to scroll the console window down, you'd also see that the network process is ended when JAmiga is.

I told you I'd be posting a screenshot! But I didn't say it would be fun or interesting though!

OpenJDK explorations

Found some info regarding the OpenJDK JVM interface:

http://fuseyism.com/openjdk/cvmi/java2vm.xhtml

I also once started to install Linux Ubuntu on my VMWare, and tried to build OpenJDK 8, to see what was needed to incorporate it into Jamiga. I found some instructions here on hg.openjdk.java.net/jdk8

Still here, still

Hi all,
I've been a bit busy lately, but I finally have some time to continue development on jamiga. I'm continuing on networking, and solving issues I find surrounding that. Right now that means stuff with the DirectByteBuffer implementation. I'm hoping to have something screenshottable soon (don't get to excited, it'll only be console stuff, no GUI).

Other than that, I'm still loooking at OpenJDK, and JamVM to some extent. With Java 7 being released, Java 8 due in 2012, and GNU Classpath hopelessly untouched since 2009 with barely Java 5 functionalty, openJDK, really seems what everyone is aiming for. Thus, the network parts tries to adhere to the OpenJDK style of implementing the class library, making the network parts relatively easy converted to another VM using OpenJDK, such as JamVM.

Still here

Since a month, back from vacation. Although I haven't done much with JAmiga lately, the project is not abonded. Last I worked on was getting network support, and that is coming along nicely. I also attended a conference (Omegapoint Competence Conference 2011 (opkoko)) that featured a run down of different garbage collecting algorithms, which really sparked my JAmiga coding spirit.

What is needed at the moment, is a more detailed plan. I will add more detailed, better planned issues to jamiga2-googlcode site, that will hopefully make the burden lesser when I do get those sparse coding sessions.

I will also try to update the blog more frequently, of any sort of progress I make.

Vacation

Ok, although there haven't been much visible activity from me lately, I still have to brag about my upcoming vacation. I'll be away from keyboard the coming two weeks.

As usual, don't take any inactivity for real inacticity or abandonment of Jamiga. Its on-going. And the other team members are here (I think).

The JAmiga team

I'm happy to announce that the JAmiga team has got two new members (which makes it relevant to even talk of a team): Thore Sittly is working on MorphOS, and Christoffer is helping out with the OS3-version.

Lately Thore added JAR-files support for MorphOS, and I'm in the process of making sure it works with OS4 aswell. Thore is also looking into adding MUI support for the AWT/spring stuff. Other new features are network support, which I am working on, and of course the ever on-going "getting everything to really work".

All in all, JAmiga might see a new release in a not to distant future -- still a beta though -- for three of our targeted platforms. We still need help from Aros-people. If you can compile stuff for Aros, please do help us (I neither have time, nor patience to install Aros at the moment). I assume our efforts in making it compile for OS3 will help us compile it for Aros aswell.

Note to self: performance test

Found a comparsion between different Java VM:s:
http://adweb.desy.de/mcs/Mst_content/TINEJavaServer_p.pdf

Should probably create a few Java-tests to test JAmiga:s capabilities. To get comparative results, I should probably install a Linux on my AmigaOne, and test JamVM and the others.

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.