Mauving forward

By: JAmiga
Posted on: 12 January 2014

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