Its been a while since an update. I've however not been entirely idle. I've updated to the latest GNU Classpath CVS version, which only added the java.io.Console class. But I found the Console class to be needed by the egit Git Hub client. Sadly, egit also requires some annotation stuff found in the not yet implemented "javalangreflect" library. Its a library with only one method in it, so it shouldn't be a biggie. Its just a matter of, well, doing it.

Commas and colons

Furthermore, I've been looking at running the Eclipse Java Compiler, ECJ. Now, don't get your hopes up on the Eclipse mentioning -- its only the compiler, no GUI stuff. But it can compile new Java source, i.e. generics and stuff, and is not limited to Java 1.4, like the old Jikes. However, with my move to the latest GNU Classpath (and some other organizational changes), ECJ won't compile things correctly.

This either due to something not being correctly configured in the new Classpath, or due to the classpath misbehaving. In order to work, Java needs to know where to find all the Java classes. Usually you can set this using the ENV variable CLASSPATH. In order to set a list of directories to search for classes, you use some sort of delimiter between the directories. In JAmiga this is comma.

CLASSPATH=JAmiga:jvm/classes,Work:classpath,

The GNU Classpath and jamvm are (or were), like everything else, mostly Unix/Linux and Windows oriented. They use either colon, or semicolon to separate classpath directories, for Unix/Linux and Windows respectively. Now, Amiga's device separator is colon, so colon can't be used. Semicolon could be used... but the way GNU Classpath and jamvm detects that a system is f.i. Windows, is based on the simple occurrence of a colon, sometimes a backslash, and sometimes the fact that it doesn't seem to be a Unix path at all. So using semicolon would sometimes suggest a Windows system (and, inherently, only allowing device names consisting of one character like in C:). Therefor I thought it better to simply "invent" a new standard, using comma. To make matters worse, sometimes files are referenced using an URI, meaning we have even more colons, like "file:Work:classpath/", or "file://Work:classpath/". More often than seldom, I see lines like "file:JAmiga:jvm/classes/Work:classpath/" being interpreted as one directory. Its a mess, really.

The dotted line

I don't know if the whole classpath-colon-slash-backslash mess, is the real culprit to ECJ not running. There are also known issues with the "dot" device, i.e. the current directory marker. The CLASSPATH ENV variable usually ends with a dot, so that the current directory is included in the search. Using f.i. "JAmiga:classpath,Work:other/classes,." should include three directories in Java's class search. However, in the Amiga world, this doesn't work, since the dot does nothing special in the Amiga OS (its just a non-existing file). A possible workaround for AmigaOS 4 would be "JAmiga:classpath,Work:other/classes,CURRDIR:". However, that will actually search for stuff in "CURRDIR:/", which is nothing else than the parent directory of CURRDIR -- if you know your Amiga DOS, you'll know that the last slash is what Windows and Unix calls "..", i.e. the parent directory. And this last slash is added on a line nestled in various for loops looking for slashes and colons, trying to both determine Windows- or unixness, as well as formatting the path correctly. And after a hard day's work... for loops and slashes really becomes a jungle.

Trying to find whose line it is... usually only makes me waste hours on youtube looking at stuff like this:

Whose line can really consume hours.