Post-traumatic Jfokus syndrome

So, Jfokus 2014 is over. I mentioned it briefly in my previous blog, but in short it's Sweden's largest Java conference, with roughly 1500 visitors, 6-7 concurrent sessions spanning three days. The speakers come from various places, like Oracle, Red Hat, Spotify, and of course, Omegapoint! My attendance is part of Omegapoint's yearly field trip to this event. I work at Omegapoint, hence my shameless plugs.

Onion to go

My takeaway from Jfokus in terms of JAmiga, I think can be summarized as a real eager in getting OpenJDK to run. There were talks of all snazzy new features OpenJDK 8 has to offer, as well as interesting insights to the general OpenJDK eco-system, and how you can contribute. Mark Reinhold from Oracle talked on Jigsaw project, which basically modularizes Java, and splits the JDK in parts. The objective is primarily to be able to ship a stripped down version of the Java platform, so those who don't for instance use a GUI or a database, can remove those part.

It was described like an onion, where you peel off the outer layers, and in the end you're left with the absolute minimum required. My, perhaps naive, plan is to take the only the core of the onion, and begin my porting efforts on that.

In my last blog I mentioned how I really can't decide on what to focus on. Even more so now. But I really want to get started on the OpenJDK route. And, in order to do that, I think my next move should be to update jamvm to the latest source with OpenJDK support. Now, I know you all amigans really, really want that GUI support. But like I previously wrote, I really don't want to repeat myself and do the same GUI job twice for both GNU Classpath, and OpenJDK -- so, I can either find a way that works for both, or focus on implementing it for OpenJDK. Because seriously, OpenJDK is the only way forward.

The cheese

Within OpenJDK there is a project called Caciocavallo (yeah, I know, cheesy name) that implements AWT GUI stuff, utilizing Swing components. This means that one wouldn't have to implement each AWT component, i.e. map native ReAction/MUI button, textbox, list, and such to its Java counterpart; it'd be sufficient to implement the more general graphics backend, that Swing uses to draw all the gadgets. Now, that doesn't mean that the work is simpler, it just means that a lot of tedious work can be skipped. This also implies that Java GUI's on AmigaOS wouldn't get an Amiga native look, but rather a Java-Swing look. Which of course is boring. But there are ways to implement look-and-feels to make stuff look more native (if I remember correctly in some cases it can actually be native gadgets, and not just a mimiced look).

Well, bla bla bla. I'm getting ahead of myself, to summarize, this is my plan forward:

• Update jamvm to latest version
• Build OpenJDK and get to know it better (i.e. build it on linux, and start from there)
• Take a close look at the Jigsaw project, and peel off all the onion rings
• See what Caciocavallo can offer

Knowing myself pretty well, I think I'll come back and re-iterate this list. And since jamvm is available in a Git repository, I really should get that Git client running.

Trying to J-focus

Somewhere, over all the place

Image found at oz.wikia.com

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.