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!