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.
