Quick prototype: Using git in NetRexx

NetRexx is a programming language for the JVM. Categorizing it is not as easy as one might think. It can be executed interpreted or compiled ahead of time, and it has a ‘scripting’ mode, that generates the class and method statements, and the mode in which all class and method statements are entered into the program source by the user. Its interpreted mode does employ the Javan compiler and can optionally leave a class file after interpretation. Consequently, it can be used in at least four ways, and these are entirely straightforward; explaining all possibilities introduces an air of complexity that is absent in reality. For this reason, I am just showing an example, and leave it up to the reader to check how it compares to other ways to get to the same result.
This year I want to show an example of what is regarded as NetRexx’s biggest advantage: easy integration in the JVM environment, making everything more straightforward, more readable, and more fun than in other languages. When encountering a new environment where work needs to be done, it suffices to look up the javadoc of the library and go for it.
Recently there was an opportunity to do some work with git – actually, there was an application to be made, and I realized its requirements overlapped for a large part with what this version management system can do. I looked around for a library and found that in jGit, from the eclipse project.
For this small experiment with git I am using NetRexx in scripting mode. This means, I am not declaring classes and just script everything in one go, on seqentially executed lines; except one method that I pasted from another program.

package com.rvjansen
import org.eclipse.jgit.
import com.eaio.uuid.UUID

trace results
builder = FileRepositoryBuilder()
repository_ = builder.findGitDir(File("/Users/rvjansen/papiamento")).readEnvironment().build()
git_ = Git(repository_)

uuid_ = newUUID()

file_ = File(repository_.getDirectory().getParent(), uuid_);
file_.createNewFile();

out = PrintWriter(BufferedWriter(FileWriter(file_)))
out.println(Date())
out.close()
git_.add().addFilepattern(uuid_).call()

git_.commit().setMessage("Added file" uuid_).call()
repository_.close()

method newUUID() returns String static
return UUID().toString.toUpperCase

I do declare a package, as this is good practice to avoid name clashes, and I am importing the packages org.eclipse.jgit and my favorite uuid package, the one that can do real timebased UUID’s following the norm – as opposed to the java UUID that does something else. In this small program the test case to be done was to version data in files kept by git, with UUID’s as filename – as not to have to use a range in a generated name. Ranges are generally bad in applications, because they come back and bite you with limitations that you did not imagine at design time.
Next we see the ‘trace results’ statement. When prototyping it is a good thing to be able to see exactly what is going on, and this is the way to do it. I am initializing a git repository, and for clarity I am using an absolute directory path. For production apps I would not do that, but when prototyping, we don’t need any relativity to make mistakes with – with absolute paths we know where everything ends up. The reference to the git repository ends up in the variable git_.
Next we are creating a file, named after a UUID that we conjure up, and write the output of Date() into it. Note that Date() comes from the standard Java library, and yes, it’s deprecated, but it beats all forms of Calendar in shortness. Obviously, these files are going to end up containing other data anyway.
After we have closed the file, we add it (its file pattern) to the git repository and we commit it, with the obligatory message. Note that all the git api’s allow for the chaining of calls. Again, I would not do that in maintainable production code, but it is great to keep examples and prototypes short.
When writing this, in two passes (first the file stuff and then the git stuff) I used interpreted execution, looked at the trace output to see that everything worked (also, to see the type info that I could leave out in NetRexx but do like to know) and for quick edit/execute turnaround.
I am perfectly happy to be able to do this in a few minutes, and I think you would be too!
Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!