(J)Ami(ga)Update

I've managed to draw a nice new icon for JAmiga! This is what I've been doing the last few days since my silly release:

Finally, I deliver some quality work. If you'd like to have this really nice eye-candy, just download the latest release.

No, seriously, that icon looks like something my lolcat managed to draw in PPaint trying to pet the Logitech (which is not far from the truth). With the help from Joel Edberg, Thomas Blatt was persuaded to draw me some really nice icons, and JAmiga can now boast with fancy icons. How they look? Well, download the update below to see.

Not only pretty pictures

This release also includes support for AmiUpdate, so you'll get freshly squeezed JAmiga automatically!

Besides AmiUpdate, these are the other changes in this new first real release.

• New script, JAmiga:JAmiga, which holds the release version. Executing this script will show you the currrent status of your JAmiga installation -- invaluable information for me when looking for errors. Besides the script spitting out various settings and assigns, it'll also try and start a tiny Java application, only to show you that it works (or not).
• Fixed the "Filer:" assign in jamvm
• Changed versioning of jamvm. The previous pre-release of jamvm had version 1.5.4, just like jamvm really has. I've now changed this, so the 1.5.4 version is reported in the full version string, and the Amiga jamvm version is reported as 1.1. I hope this doesn't pose problems in future AmiUpdates (since 1.5.4 is higher than 1.1)
• Removed debugging from javanio.library making it less slow.
• And, of course, the new shiny icons!

Java application seen working

Now, my ill-fated Twitter client isn't really the killer application we all wanted, I guess. But other stuff has been reported working:

• The reason for fixing javanio.library, was primalrily that it caused problems running Smushit, as reported by asymetrix over at amigaworld.net. With my tiny fix it now actually works. It turned out that writing the smushed files took too long time, timeing out the Yahoo server.
• Chris_Y reported that jasypt (some sort of encryption thingie) worked, after giving it some proper command-line love.

It's really nice to see the amigans eagerness in trying out JAmiga. I will myself try a few things I've been looking at running, and hope that you all keep up the good work! I will keep on reporting what has been seens working.

Enough rambling, show me the download!

You can install this 1.1 version over your current installation, or to a clean system.
If you have the 0.1.0 version installed, you can uncheck the GNU Classpath choice -- nothing has changed there.
Follow the link below to download. Unpack the archive with UnArc (lha sometimes misses the the flags for the scripts)

• JAmiga-1.1.lha

And keep an eye on AmiUpdate!

A silly release

Downloads available

So, I haven't done much lately on JAmiga, but I'd thought I at least give you something to play with. I've prepared an archive with everything you need to install a Java environment on AmigaOS 4.

And first of all: its still considered beta!

Here are the downloads:

• jamiga-0.1.0.lha
• JAmigaTwitter.lha

Bugs

• If you have installed JAmiga on a drive with international characters in it, like "Hårddisk", AmigaOS will ask you to insert the disk "H?rddisk". You can either assign "H?rddisk" to the real "Hårddisk", or alter your user-starup, and assign JAmiga to the partition name, like DH1:. I guess this also applies for drawers with international names.

Installation

The installation of the main JAmiga archive is pretty straight forward. Just unpack and stat the installer. The "installation" of the silly Twitter client is also easy - just unpack to wherever you want it.

Actually a silly release

I say silly Twitter client, because it is. To be totally honest, this entire release is a bit silly, at least from a user perspective. Not that JAmiga doesn't work - it does indeed work. Only that we don't have so much content to play with. My hope is however that someone with some Java skills will start developing, or find some novel stuff we can run. The source code for my silly Twitter client is included. And you get a Java compiler in the installation! So its only a matter of starting to develop and do stuff better!

Running the silly client

After you've installed JAmiga, you can download and unpack the Twitter client.

Start the Twitter client by double click the JAmigaTwitter.jar file.

You'll be asked for input. This first time you can simply run it, and you'll eventually be presented with some info on how to make it do stuff. Notice the "eventually" - depending on your machine it might take a while to start it, and there's no splash screen. (On my A1XE it starts in 5 seconds, and on my X1000 in like 3 seconds.)

The first you have to do is to allow the Java Twitter client to access your data.
Double click JAmigaTwitter.jar again. But this time, enter "auth" at the end of the input.

After running it this time, JAmiga Twitter will... well... its actually up to you to see what it'll do. But you will need to log into your Twitter account and give access to the "JAmigaTwotter" (sic!) client.

You can of course start the JAmiga from the Shell. You simply point to your JAR file from the java.script:

1.System:> JAmiga:java.script DH1:SillyApps/JAmigaTwitter.jar

With the client you can post status updates on your wall (or whatever it's called on Twitter), fetch your status (Ousp. Just noticed that you can't fetch your own status, some sort of bug), and do query searchs. The query search returns some sort of HTML, and searching for Amiga will only get you spanish people looking for girls.

Searching for geeky amiga stuff is hard...

What's next?

I will continue to update and improve JAmiga, as well as create some Java content. Even if I named this a silly release, I wanted to get it out there for you to test and play with. Hopefully all you Amiga Java coders will find it nice to play with. I will try to produce some tutorials on how to get started coding little Java applications. If you have questions, don't hesitate to ask me.

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.