måndag 3 februari 2014

Trying to J-focus

Somewhere, over all the place

It feels like I'm all over the place currently. I can't decide what to focus on. I have however managed to implement a new library: javalangreflect.library. I told you about it previously when trying to run the JGit git client. I reached some success, as in "it started".
See output below:

Get git-ing with it

3.Mauve:Projects/jgit/jgit> jamiga:jamvm -Dgnu.classpath.home.url=file:jamiga:classpath org.eclipse.jgit.pgm.Main
jgit --git-dir GIT_DIR --help (-h) --show-stack-trace --version command [ARG ...] The most commonly used commands are: add Add file contents to the index archive zip up files from the named tree branch List, create, or delete branches checkout Checkout a branch to the working tree clone Clone a repository into a new directory commit Record changes to the repository config Get and set repository or global options daemon Export repositories over git:// describe Show the most recent tag that is reachable from a commit diff Show diffs fetch Update remote refs from another repository gc Cleanup unnecessary files and optimize the local repository init Create an empty git repository log View commit history ls-remote List references in a remote repository ls-tree List the contents of a tree object merge Merges two development histories push Update remote repository from local refs reflog Manage reflog information reset Reset current HEAD to the specified state rm Stop tracking a file show display one commit status Show the working tree status tag Create a tag version Display the version of jgit 3.Mauve:Projects/jgit/jgit>

However, trying to get status from a repository only resulted in AmigaDOS requests for disks named "git:". I don't know how its supposed to work, but the Git URI does indeed look like "git://git.berlios.de/jamvm". So I'm not very surprised. I guess I really should try and get the Git client working on another Java system first. So that I know my command line syntax is correct.

Trying to J-focus

This week I'm however really Java focused, as I'm attending Sweden's largest Java conference: Jfokus. Today I listened to stuff on Java 8 and Java 7. Cool stuff indeed! And it makes me really want to go the OpenJDK route, and get us updated, from Java 5 to Java 8. But I also want to get some GUI stuff in order, before I commence a new, I'm fearing long-going route. Furthermore, I really don't want to WET, but rather stay DRY; so I keep telling myself "Don't Repeat Yourself". After my ill-fated Git try (but in some ways successful, I got a new library!), I looked at the GUI code in JAmiga. And in GNU classpath in general. And in OpenJDK. And then I got tired. There are so many classes! And so many native calls!

Gad only knows

Regarding the JAmiga GUI/AWT implementation, it uses GadTools. I would like to use ReAction, since its, a) what OS4 should use, and b) I think its easier to connect it to Java, with it being object oriented. In essence I'm naïvely thinking it'd be sufficient with one native call to the BOOPSI call NewObject. Now, I know that it isn't that easy. But I think its far easier than using GadTool's CreateGadget.

The talented coder Andy, broadblues, Broad, with his phenomenal digital art creating program SketchBlock, has in the accompanying ProAction ARexx GUI creation package, included the source. Which I have peeked at. So, one option is to take inspiration, or even code from that (not without asking though!), and another option could perhaps be to add ARexx support to JAmiga, and get GUI support that way. The last ARexx option is tempting, since it would give me an oportunity to get ARexx to JAmiga, which would be utterly cool. What talks against it, is however speed. It would be a nasty web of intricate Java to native C-code, wrapped in strings sent to ARexx, back to native C-code, doing GUI, back to ARexx, back to native-C, back to Java. And then iterate through that scenario a few times for every little button we want in our GUI. Not something you would like to run big beasts like Eclipse or NetBeans on.

What about MUI, I hear some of you say? Well, I'm not ruling out MUI in any way. Its just that I myself have very limited knowledge of MUI. And I basically want to come up with a solution that works for both OpenJDK and GNU classpath, before I implement it for real. If that solution uses ReAction, it would be easy-peasy to change it to MUI anyways, since they both are BOOPSI.

söndag 12 januari 2014

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.

söndag 5 januari 2014

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!

söndag 29 december 2013

Java Developer's Kit

Tiny update for Java developer's

On the JAmiga support forum on amigans.net I've added a little note on a developer's package available on AmiUpdate:

On AmiUpdate you can find an update consisting of a few developer's files. There's a new Java compiler, a simple example, as well as documentation.

Just update your system, go to JAmiga:Documents/Developer.guide, and you're just minutes away from compiling your own applications.

I'll try to add more info on how you can use it with various third-party jar files.

New year's resolution?

I managed to get this tiny update out before the year has ended. Next year, I'll try to be better in getting stuff out there. Even it's only small things. I've been a bit too silent the last two months, but other things in life has taken up my time.

Over and out. And a happy new year!

måndag 4 november 2013

JAmiga 1.2

JAmiga 1.2 is currently in os4depot's upload queue. After its been approved and uploaded, I will add the update to AmiUpdate -- so you who already have v 1.1 installed can wait for the AmiUpdate update.

This is a full release: all required components are in the archive. Future updates of the individual components will be available with AmiUpdate as usual.

Change log

  • Added support for java.io.Console in javanio.library
  • Changed drawer hierarchy of JAmiga files in order to ease update and maintainability
  • Minor fixes in jamvm
  • New default and regular icons from Mason
  • The environmental variables (BOOTCLASSPATH and LD_LIBRARY_PATH) are no longer needed

Thanks to all of you

I'd like to, in no particular order, thank you all who have contributed in any way to JAmiga. To mention a few:

  • Joel Edberg for testing (and constant nagging me for updates)
  • Thomas Blatt for the first set of icons
  • Martin Mason Merz for the 2nd set of icons, including DefIcons
  • All you kind lovely amigans for support, cheering and donations! Without you, my work would be profoundly pointless!

And, of course, credit where credit is due. This is a continuation of the original JAmiga effort, by Peter Werno and André Dörffler. Even though there has been lots of changes, and it now also sports the JamVm JVM by Robert Lougher.

Nope, now I have to press "Publish" -- the os4depot upload has been approved!

torsdag 17 oktober 2013

Continuing mauve testing

Slowly but surely I'm working through the mauve suite. Currently, focus is on java.io.
Yesterday I got these fails:
FAIL: java.io.File.ReadMethods
FAIL: java.io.File.ExecuteMethods
FAIL: java.io.File.newFileURI
FAIL: java.io.File.WriteMethods
FAIL: java.io.File.URI
FAIL: java.io.File.security
FAIL: java.io.File.UnicodeURI
FAIL: java.io.File.createFile
FAIL: java.io.File.newFile
FAIL: java.io.File.emptyFile
FAIL: java.io.RandomAccessFile.security
After running these tests:
gnu.testlet.java.io.File.canWrite
gnu.testlet.java.io.File.ReadMethods
gnu.testlet.java.io.File.ExecuteMethods
gnu.testlet.java.io.File.newFileURI
gnu.testlet.java.io.File.WriteMethods
gnu.testlet.java.io.File.URI
gnu.testlet.java.io.File.security
gnu.testlet.java.io.File.list
gnu.testlet.java.io.File.listFiles
gnu.testlet.java.io.File.UnicodeURI
gnu.testlet.java.io.File.createFile
gnu.testlet.java.io.File.newFile
gnu.testlet.java.io.File.jdk11
gnu.testlet.java.io.File.emptyFile
gnu.testlet.java.io.CharArrayReader.OutOfBounds
gnu.testlet.java.io.CharArrayReader.MarkReset
gnu.testlet.java.io.CharArrayReader.ProtectedVars
gnu.testlet.java.io.CharArrayReader.SimpleRead
gnu.testlet.java.io.StringReader.Test
gnu.testlet.java.io.FilterInputStream.MarkReset
gnu.testlet.java.io.FilterInputStream.SimpleRead
gnu.testlet.java.io.RandomAccessFile.security
gnu.testlet.java.io.RandomAccessFile.randomaccessfile
gnu.testlet.java.io.RandomAccessFile.jdk11
gnu.testlet.java.io.RandomAccessFile.setLength
gnu.testlet.java.io.PushbackInputStream.Unread
gnu.testlet.java.io.PushbackInputStream.ProtectedVars
gnu.testlet.java.io.PushbackInputStream.BufferOverflow
gnu.testlet.java.io.FileDescriptor.jdk11
gnu.testlet.java.io.Serializable.ParentReadResolve
gnu.testlet.java.io.Serializable.readResolve
gnu.testlet.java.io.Serializable.ParentWriteReplace
gnu.testlet.java.io.Serializable.MySerializable
gnu.testlet.java.io.Serializable.BreakMe
gnu.testlet.java.io.Serializable.MyBreakMe
gnu.testlet.java.io.Serializable.BreakMeTestSer
gnu.testlet.java.io.FileWriter.jdk11
gnu.testlet.java.io.Writer.Test
gnu.testlet.java.io.ObjectStreamClass.DefinedNotStatic
gnu.testlet.java.io.ObjectStreamClass.DefinedNotFinal
gnu.testlet.java.io.ObjectStreamClass.Test
gnu.testlet.java.io.ObjectStreamClass.NotSerial
gnu.testlet.java.io.ObjectStreamClass.Serial
gnu.testlet.java.io.ObjectStreamClass.C
gnu.testlet.java.io.ObjectStreamClass.A
gnu.testlet.java.io.ObjectStreamClass.B
gnu.testlet.java.io.ObjectStreamClass.ProxyTest
gnu.testlet.java.io.ObjectStreamClass.Defined
gnu.testlet.java.io.SequenceInputStream.Test
gnu.testlet.java.io.FileInputStream.security
gnu.testlet.java.io.FileInputStream.fileinputstream
gnu.testlet.java.io.FileInputStream.read
gnu.testlet.java.io.BufferedInputStream.ZeroRead
gnu.testlet.java.io.BufferedInputStream.MarkReset
gnu.testlet.java.io.BufferedInputStream.Skip
gnu.testlet.java.io.BufferedInputStream.BigMark
gnu.testlet.java.io.BufferedInputStream.ProtectedVars
gnu.testlet.java.io.BufferedInputStream.SimpleRead
gnu.testlet.java.io.OutputStreamWriter.jdk11
gnu.testlet.java.io.LineNumberInputStream.Test
gnu.testlet.java.io.FilterReader.MarkReset
gnu.testlet.java.io.FilterReader.SimpleRead
gnu.testlet.java.io.Reader.Test
gnu.testlet.java.io.ObjectInputStream.registerValidation
gnu.testlet.java.io.ObjectInputStream.readResolve
gnu.testlet.java.io.ObjectInputStream.ReadResolveHelper
gnu.testlet.java.io.ObjectInputStream.security
gnu.testlet.java.io.ObjectInputStream.TestObjectInputValidation
gnu.testlet.java.io.ObjectInputStream.ClassLoaderTest
gnu.testlet.java.io.LineNumberReader.Test
gnu.testlet.java.io.LineNumberReader.mark
gnu.testlet.java.io.LineNumberReader.Test2
gnu.testlet.java.io.ByteArrayInputStream.MarkReset
gnu.testlet.java.io.ByteArrayInputStream.ProtectedVars
gnu.testlet.java.io.ByteArrayInputStream.SimpleRead
gnu.testlet.java.io.ObjectOutputStream.StreamDataTest
gnu.testlet.java.io.ObjectOutputStream.useProtocolVersion
gnu.testlet.java.io.ObjectOutputStream.security
gnu.testlet.java.io.BufferedReader.boundary
gnu.testlet.java.io.BufferedReader.MarkReset
gnu.testlet.java.io.BufferedReader.mark
gnu.testlet.java.io.BufferedReader.SimpleRead
gnu.testlet.java.io.StreamTokenizer.commentchar
gnu.testlet.java.io.StreamTokenizer.misc
gnu.testlet.java.io.StreamTokenizer.newline
gnu.testlet.java.io.StreamTokenizer.WordWhiteChars
gnu.testlet.java.io.StreamTokenizer.Test
gnu.testlet.java.io.StreamTokenizer.slashslash
gnu.testlet.java.io.StreamTokenizer.slashstar
gnu.testlet.java.io.InputStreamReader.hang
gnu.testlet.java.io.InputStreamReader.utf8
gnu.testlet.java.io.InputStreamReader.getEncoding
gnu.testlet.java.io.InputStreamReader.jdk11
gnu.testlet.java.io.InputStreamReader.except
gnu.testlet.java.io.BufferedWriter.Test
gnu.testlet.java.io.DataInputStream.readLine
gnu.testlet.java.io.DataInputStream.ReadStream2
gnu.testlet.java.io.DataInputStream.ReadReference
gnu.testlet.java.io.DataInputStream.ReadStream
gnu.testlet.java.io.DataInputStream.ReadReference2
gnu.testlet.java.io.FileReader.jdk11
gnu.testlet.java.io.PushbackReader.Unread
gnu.testlet.java.io.PushbackReader.BufferOverflow
gnu.testlet.java.io.PrintWriter.checkError
gnu.testlet.java.io.PrintWriter.jdk11
gnu.testlet.java.io.InputStream.Test
gnu.testlet.java.io.CharArrayWriter.BasicTests
gnu.testlet.java.io.CharArrayWriter.ProtectedVars
gnu.testlet.java.io.ByteArrayOutputStream.subclass
gnu.testlet.java.io.ByteArrayOutputStream.write
gnu.testlet.java.io.OutputStream.Test
gnu.testlet.java.io.PipedReaderWriter.Test
gnu.testlet.java.io.PipedReaderWriter.PipedTestWriter
gnu.testlet.java.io.ObjectInputOutput.OutputTest
gnu.testlet.java.io.ObjectInputOutput.LoopSerializationTest
gnu.testlet.java.io.ObjectInputOutput.SerTest
gnu.testlet.java.io.ObjectInputOutput.Compat2
gnu.testlet.java.io.ObjectInputOutput.Compat1
gnu.testlet.java.io.ObjectInputOutput.Test
gnu.testlet.java.io.ObjectInputOutput.Deserializable
gnu.testlet.java.io.ObjectInputOutput.SerBase
gnu.testlet.java.io.ObjectInputOutput.SerializableLoopB
gnu.testlet.java.io.ObjectInputOutput.ProxySerializationTest
gnu.testlet.java.io.ObjectInputOutput.InputTest
gnu.testlet.java.io.ObjectInputOutput.SerializableLoopA
gnu.testlet.java.io.ObjectInputOutput.ExtTest
gnu.testlet.java.io.ObjectInputOutput.HierarchyTest
gnu.testlet.java.io.BufferedOutputStream.Test
gnu.testlet.java.io.BufferedOutputStream.helper
gnu.testlet.java.io.BufferedOutputStream.interrupt
gnu.testlet.java.io.PipedStream.PipedStreamTestWriter
gnu.testlet.java.io.PipedStream.receive
gnu.testlet.java.io.PipedStream.Test
gnu.testlet.java.io.PipedStream.close
gnu.testlet.java.io.FilePermission.simple
gnu.testlet.java.io.FilePermission.traversal2
gnu.testlet.java.io.FilePermission.traversal
gnu.testlet.java.io.FilterWriter.MyFilterWriter
gnu.testlet.java.io.FilterWriter.write
gnu.testlet.java.io.StringBufferInputStream.MarkReset
gnu.testlet.java.io.StringBufferInputStream.ProtectedVars
gnu.testlet.java.io.StringBufferInputStream.SimpleRead
gnu.testlet.java.io.FileOutputStream.append
gnu.testlet.java.io.FileOutputStream.fileoutputstream
gnu.testlet.java.io.FileOutputStream.security
gnu.testlet.java.io.FileOutputStream.write
gnu.testlet.java.io.FileOutputStream.jdk12
gnu.testlet.java.io.StringWriter.Test
gnu.testlet.java.io.FilterOutputStream.write
gnu.testlet.java.io.PrintStream.subclass
gnu.testlet.java.io.PrintStream.encodings
gnu.testlet.java.io.Utf8Encoding.WriteRead
gnu.testlet.java.io.Utf8Encoding.mojo
gnu.testlet.java.io.Utf8Encoding.ReadReference
gnu.testlet.java.io.DataOutputStream.writeUTF
gnu.testlet.java.io.DataOutputStream.WriteRead2
gnu.testlet.java.io.DataOutputStream.WriteRead
And, tonight I fixed these issues:

java.io.File.ReadMethods
java.io.File.ExecuteMethods
java.io.File.WriteMethods
So, slowly, but surely. Even though most of these errors aren't show stoppers, they still need to be fixed.

söndag 29 september 2013

File me a river

I finally found what was wrong, and why ECJ couldn't compile like it should. I missed my modifications made to jva.io.VMFile, the native layer between Java files and Amiga files. With this in place, ECJ can now compile correctly. So, no more need to use jikes.

Connecting the dots

However, the file handling is not entirely solved just yet. I'm still pondering on how to solve the dot file, ".", denoting the current directory. I think it's a rather silly little marker; to me as an amigan it serves no real purpose. It just sits there. On unix, a path like "/dev/./././" is really just "/dev/". So, I don't really see the point (pun intended).

Picture stolen from bigactivities.com

Anyhow, I think I have to handle it somehow, since there'll probably be a few applications assuming that it works (amongst them jamvm). The "/dev/" example also leads me to one such unix-amiga inconsistency. In the mauve test suite, a test exists involving files and URI's. The test wants the URI of file "/dev/tmp" to be just "/dev/tmp" (or rather the URI "file://dev/tmp"), whereas the current JAmiga implementation happily tries to make that into "file://SYS:System//dev/tmp/", when I guess it really should be just "file://dev/tmp/" (internally represented as "dev:tmp/"). And where AmigaDOS thinks the path "SYS:System//Utilities", really is "SYS:Utilities", JAmiga thinks its just "SYS:System/Utilities".

Annoying.