Trying to J-focus

  • By: JAmiga
  • Posted on: 3 February 2014

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.