Mauve tests, partial result

I thought I'd share the current status of my Mauve tests. I haven't had much time these last few days, but I have atleast a partial Mauve run:

TEST FAILED: 1 of 1 checks failed java.net.InetAddress.getCanonicalHostName
TEST PASSED (2 checks) java.net.InetAddress.getByName
TEST PASSED (14 checks) java.net.InetAddress.getByAddress
TEST PASSED (6 checks) java.net.InetAddress.getAllByName

TEST FAILED: 16 of 51 checks failed java.io.File.jdk11
TEST FAILED: 8 of 15 checks failed java.io.File.emptyFile
TEST PASSED (0 checks) java.io.File.createFile
TEST FAILED: uncaught exception java.io.File.canWrite
TEST PASSED (1 checks) java.io.DataOutputStream.writeUTF
TEST FAILED: 6 of 9 checks failed java.io.DataOutputStream.WriteRead2
TEST FAILED: 4 of 6 checks failed java.io.DataOutputStream.WriteRead
TEST FAILED: 6 of 6 checks failed java.io.DataInputStream.ReadReference2
TEST FAILED: 1 of 5 checks failed java.io.DataInputStream.ReadReference
TEST PASSED (37 checks) java.io.DataInputStream.readLine
TEST PASSED (2 checks) java.io.CharArrayWriter.ProtectedVars
TEST PASSED (4 checks) java.io.CharArrayWriter.BasicTests
TEST PASSED (1 checks) java.io.CharArrayReader.SimpleRead
TEST PASSED (4 checks) java.io.CharArrayReader.ProtectedVars
TEST PASSED (2 checks) java.io.CharArrayReader.OutOfBounds
TEST PASSED (4 checks) java.io.CharArrayReader.MarkReset
TEST PASSED (9 checks) java.io.ByteArrayOutputStream.write
TEST PASSED (12 checks) java.io.ByteArrayOutputStream.subclass
TEST PASSED (1 checks) java.io.ByteArrayInputStream.SimpleRead
TEST PASSED (5 checks) java.io.ByteArrayInputStream.MarkReset
TEST PASSED (4 checks) java.io.ByteArrayInputStream.ProtectedVars
TEST PASSED (2 checks) java.io.BufferedWriter.Test
TEST PASSED (1 checks) java.io.BufferedReader.SimpleRead
TEST PASSED (2 checks) java.io.BufferedReader.MarkReset
TEST PASSED (19 checks) java.io.BufferedReader.mark
TEST PASSED (5 checks) java.io.BufferedReader.boundary
TEST PASSED (6 checks) java.io.BufferedOutputStream.interrupt
TEST PASSED (2 checks) java.io.BufferedOutputStream.Test
TEST PASSED (5 checks) java.io.BufferedInputStream.ProtectedVars
TEST PASSED (5 checks) java.io.BufferedInputStream.SimpleRead
TEST PASSED (2 checks) java.io.BufferedInputStream.Skip
TEST PASSED (1 checks) java.io.BufferedInputStream.ZeroRead
TEST PASSED (2 checks) java.io.FileDescriptor.jdk11
TEST PASSED (24 checks) java.io.BufferedInputStream.BigMark
TEST PASSED (2 checks) java.io.BufferedInputStream.Skip
TEST PASSED (9 checks) java.io.Reader.Test

TEST PASSED (5 checks) java.lang.Thread.getThreadGroup
TEST PASSED (57 checks) java.lang.Thread.priority
TEST PASSED (11 checks) java.lang.Thread.join
TEST PASSED (20 checks) java.lang.Thread.security10
TEST PASSED (8 checks) java.lang.Thread.name
TEST PASSED (4 checks) java.lang.Thread.isAlive
TEST FAILED: 24 of 27 checks failed java.lang.Thread.security
TEST PASSED (9 checks) java.lang.Thread.daemon
TEST PASSED (79 checks) java.lang.Thread.sleep
TEST FAILED: 3 of 21 checks failed java.lang.Thread.insecurity
TEST PASSED (7 checks) java.lang.Thread.contextClassLoader
TEST PASSED (11 checks) java.lang.Thread.interrupt
TEST FAILED: 3 of 6 checks failed java.lang.Thread.stop
TEST PASSED (2 checks) java.lang.ClassLoader.redefine
TEST PASSED (3 checks) java.lang.ClassLoader.Resources
TEST PASSED (13 checks) java.lang.ClassLoader.findLoadedClass
TEST PASSED (27 checks) java.lang.ClassLoader.BootDefinedPackages
TEST FAILED: 4 of 5 checks failed java.lang.ClassLoader.security
TEST PASSED (16 checks) java.lang.ClassLoader.loadClass
TEST PASSED (13 checks) java.lang.ClassLoader.initialize
TEST FAILED: 2 of 3 checks failed java.lang.SecurityManager.thread
TEST: java.lang.ProcessBuilder.simple

You can see there are some issues with the security manager stuff. The security is in this case security as in which classes in what contexts can execute certain sensitive or possibly dangerous methods. This involves stuff like not allowing everyone to call exitVM, or write to files, et cetera. There is also methods that are deprecated, and in JamVM does nothing, like java.lang.Thread.stop.

One more thing to note is that this is not a complete list, there are a few more I need to run, but the last failed test (not shown in list) actually locked the VM, so I had to break it (it was a well-behaved lock up, I could Ctrl-C it).

Other than Mauve testing I've begun to package a milestone 1 archive, which I hope to get done soon.

I tawt I taw a putty tat

I just have to show you this tweet.

Isn't it like the best thing ever written in less than 140 characters?

Like you might have guessed, the tweet is tweeted from the oh-so elegant JAmigaTwitter console. Which evidently works.

Dare I say, just two more wee...?

I'm currently in the process of packaging things together in order to release a beta of JamVM, together with GNU Classpath 0.99 and a at least two demonstration programs. This will, as mentioned on the JAmiga bounty page allow AmigaOS 4 users to run Java 1.5, with the exception of GUI and other more advanced stuff. So, watch this space!

Some sort of success

This is getting annoying, but I do have had some success, just this very minute. Even though it doesn't work.

Now, what you see is my minimal Twitter console client. It works relatively straight forward, you get a link to open in your browser in order to authenticate the Twitter console. When you have logged in to Twitter, and authorized the application (currently named "Jamiga Twotter"), you get a PIN which you should enter into the console application.

An error indicating some sort of success

The result you can the see further down in the picture: Twitter responds with an error, saying that the REST API v1 is no longer active. So, it turns out, that the Twitter4J client I tried out is no longer supported. And this happened recently, in March 2013. I had my Twitter console application running nicely on another platform just the other day, so even though I probably should be a bit mad, I'm actually happy getting this error. Because this is a valid really great error! It means that what I've done, actually works. The JVM can communicate with outside servers, and he whole Twitter API parsing works. So this test actually proves that a lot of stuff is working.

Now, to the avail, the Twitter4J people (who's java implementation I'm using) are saying they've fixed it. So it look like I'm just an update and configuration away from having a working Twitter implementation on JAmiga.

Oh, and by the way, I also fixed the "double trouble" with converting doubles to strings.

Amiga paths

I eventually got some work done this week, but still not quite there. The problems regarding the reported file size was easily fixed, once I saw the error. It was a rather embarassing error. Apparantely the Java type "long" was defined as a 32 bit value, where Java wants a 64 bit type. Easily fixed, and kind of in the areas of what I thought was wrong. Following that fix, my current problem arise around opening file through the Java URL class, i.e. on the "file://SYS:s/startup-sequence"-form. I had the feeling this would come and bite me, sooner or later. GNU Classpath supports Unix and Windows paths, and it decides which system is in use by checking the file separator; if its backslash, its Windows, if it isn't we have Unix. A very pragmatic look, but not terribly allowing for other systems. I'm currently going through the Java class hierarchy to try and find where exactly it doesn't work, because in some cases it works, and in other cases JamVM is trying to reach volumes named "/SYS:".

So, I'm think I'll be able to solve this in the next week, and I can only hope I don't stumble upon some other big issues. I'm counting on minor issues, though. 

Slight delay

The deadline for the bounty is closing in on me. Sadly I won't have much time to work on it this week... so my fear is that the deadline will be delayed. Hopefully only a few days though.

My recent progress has surfaced a few specific issues I have to deal with prior releasing a beta version.

A piece of pie

One of the bounty goals is an SSH-client. The more simple telnet variant works, as can be seen in previous post. However, trying with SSH bubbles up an issue I'm well aware of, that I thought I could wait with. Converting the string "3.1415" to the actual value 3.1415, is actually performed in native code, meaning I need to implement the support for it. Its a rather complex amount of code, but luckily I don't have to do it myself since it has been taken care of in the GNU Classpath implementation. The existing code however doesn't compile out-of-the-box, so I have ignored it for now. I'm hoping this will only be a matter of hours fiddling with the existing source to make it compile in the Amiga environment. And then I'm hoping that the SSH client won't have anymore issues.

The file was how big?

One other issue, that I perhaps could get away without resolving immediately, is a strange issue with how classes are loaded by the JVM. Up until this point, all my classes have been residing in the bootclasspath, as opposed to the ordinary classpath. The bootclasspath should contain all classes needed for the JVM to start, and "user" classes, or rather, external thirdparty jars (for instance the SSH library, or the Twitter4J API) should reside in the ordinary classpath. The ordinary class loader uses Java code to load the classes while the bootclasspath loader uses native code. And there seems to be some issues with how my Amiga implementation reports the size of class files, because every time the JVM want's to allocate memory for the class to load, I get an OutOfMemory exception. Looking at my code and debugging, I really can't see where the size get messed up. The Amiga part correctly reports ordinary sizes, but on the Java side its almost as if using uninitialized variables, or some sort of unsigned/signed error.

Given enough time this week, I believe I could have solved these issues in time. However, my current workload and various after work meetings, minimize my JAmiga time to a value near zero.