Mauving forward

I've been running some more Mauve-tests in the java.io package. The tests in java.io are mostly running, beside these:

• java.io.File.WriteMethods
• java.io.File.ReadMethods
• java.io.File.ExecuteMethods
• --
• java.io.File.newFileURI
• java.io.File.WriteMethods
• java.io.File.URI
• java.io.File.UnicodeURI
• --
• java.io.File.security
• java.io.RandomAccessFile.security
• --
• java.io.File.createFile
• java.io.File.newFile
• java.io.File.emptyFile

I've divided them in four section (striked tests are those I've recently fixed).

Protection bits and pieces

The first, Read and Execute methods, are only minor stuff regarding protection bits (i.e. RWED and such). I think it's easily fixed, it might even differ on which Amiga files system I use for the test.

URI, who? Geller?

The second, the URI methods, surround my previous discussed Amiga paths: File me a river, Amiga paths.
So, I'm back struggling with this. To the avail is a nifty class I just found in java.io: PlatformHelper! Reading from the javadoc:

/**
 * We had many changes in File.java, URLStreamHandler.java etc.
 * to handle path representations on different platforms
 * (Windows/Unix-family).
 * Finally we'd like to collect all these ad hoc codes into this
 * utility class.
 *       --Gansha
 */

How convenient.
However, initial tests has got me stumped, as the PlatformHeloper doesn't seem to affect those areas I would have assumed.

URI, where? Bending spoons, eyh?

The third section surrounds security, which gives me exceptions indicated relation to the URI issue in section two:

   java.lang.ExceptionInInitializerError
   at java.lang.SecurityManager.(SecurityManager.java:180)
   at gnu.testlet.TestSecurityManager.(TestSecurityManager.java:132)
   at gnu.testlet.java.io.File.security.test(security.java:94)
   at RunnerProcess.runtest(RunnerProcess.java:379)
   at RunnerProcess.runAndReport(RunnerProcess.java:434)
   at RunnerProcess.main(RunnerProcess.java:242)
java.lang.ExceptionInInitializerError
   at java.lang.SecurityManager.(SecurityManager.java:180)
   at gnu.testlet.TestSecurityManager.(TestSecurityManager.java:132)
   at gnu.testlet.java.io.File.security.test(security.java:94)
   at RunnerProcess.runtest(RunnerProcess.java:379)
   at RunnerProcess.runAndReport(RunnerProcess.java:434)
   at RunnerProcess.main(RunnerProcess.java:242)
Caused by: java.nio.channels.UnresolvedAddressException
   at gnu.java.nio.SocketChannelImpl.connect(SocketChannelImpl.java:162)
   at gnu.java.net.PlainSocketImpl.connect(PlainSocketImpl.java:281)
   at java.net.Socket.connect(Socket.java:463)
   at java.net.Socket.connect(Socket.java:414)
   at gnu.java.net.protocol.ftp.FTPConnection.(FTPConnection.java:255)
   at gnu.java.net.protocol.ftp.FTPConnection.(FTPConnection.java:223)
   at gnu.java.net.protocol.ftp.FTPURLConnection.connect(FTPURLConnection.java:121)
   at gnu.java.net.protocol.ftp.FTPURLConnection.getInputStream(FTPURLConnection.java:165)
   at java.net.URL.openStream(URL.java:737)
   at java.security.Security.loadProviders(Security.java:131)
   at java.security.Security.(Security.java:80)
   at java.lang.SecurityManager.(SecurityManager.java:180)
   ...5 more

Looking at the debug logs of this, indicates that the SecurityManager class wants to open a security file, and it seems to want to resolve this file by using an FTP connection. Even though the file is local. And this most likely is due to the Amiga path from the Java standpoint looks like an URL; "jamiga:foo/bar/security.properties". I've seen a spot where the "foo" can be mistaken for a port number, but silently ignored due to not being a number. Or it might be somewhere else. Investigation is on-going.

Uri, hurry up!

The fourth section, or rather the createFile-test fails because it takes too long to complete. It might be due to that it truly takes too long, or it might be some other error that causes it to take too long. Only time will tell, I guess.

Coming attractions

Other that Mauve-testing, I'm trying to do a follow-up on the previously released developer's kit. But those tries are hindered by the issues just mentioned.

Are you having trouble installing JAmiga 1.2?

From reports on the support forum on amigans.net, JosDuchIt reported some troubles installing and running JAmiga. The culprit was an innocent space in the name of the driver where JAmiga was installed.

I'm ashamed to say that my installation script didn't support spaces in partition or drawer of installation path. I myself have had spaces in my partition names, f.i. "AmigaOS 4:", so its a bit silly i didn't catch this. I'm assuming other's have had similar problems, but only JosDuchIt had the courage, and sense to report it!

Given the Amiga community's size, its really crucial for developers to get some sort of user feedback. I'm actually pretty spoiled with a rather large buzz, all things considering. So, its not so much for JAmiga's users, but more for the sake of all the other program on os4depot and elsewhere: please, if you download something and it doesn't work - report it. Most, if not all, developers want user feedback, because they put a great deal of effort into just uploading stuff to os4depot.

I'm really throwing bricks in my own glass house, but its one of my new years resolutions: to give more feedback for programs I regularly use.

Updated installer available

Anyway, the error with the installer has now been fixed, and the JAmiga 1.2 archive on os4depot should be able to install nicely - even with spaces. Remember to AmiUpdate after installation!

Some background info

I thought I'd share some of my installations script behavior. It is in most regards a pretty normal install script. Howver, the Java classes (i.e. all the class files building up the Java SE standard), are in-fact bundled in the JAmiga archive as lha archives. The entire Java SE standard consist of roughly 3700 classes, and in essence the same amount of files. So I wanted to lessen the initial unpacking to a minimum, and leave the most unpacking to the install script. Therefor UnArc handles the unpacking during installation. And I missed a pair of quotes surrounding the destination drawer, hence the space issue.

Other things I've included in the install script are the preview and choice of icons. For this I use Multiview with its companioning ARexx port to close the preview.

In order to open the DefIcons tutorial, I use the AmigaOS 4 standard program "URLOpen". One future enhancement I'm thinking of is to automatically launch AmiUpdate when the installation has been performed, so any new updates have a better chance of being noticed and installed.

And these are some of my favorite things with version 4 of AmigaOS. As a developer I can actually rely on a few things being installed by default. I don't need to weigh down my archive with support files. Now, I wasn't much of a developer in the 3.x era, but I remember installing stuff often required the installer to supply the lha unarchiver and such. Furthermore, with the power of ARexx, a lot of stuff can be done from scripts, which I'm just realizing writing a few AmigaGuides for JAmiga.

Anyhow, I should get back to writing and releasing my Twitter application. Not because its ground breaking or earth shattering in any way, its only because it is a great example of what can be done with JAmiga today, using third party JAR files.

Tata!