So, I’ve finally got sick of the unusable command line interface to the Scala interpreter.
Don’t get me wrong, I like command line interfaces. But I’ve always found command line interfaces written in Java to be pretty horribly unusable, and the variety of different quirks shown by the scala one between windows and linux is pretty gruesome.
Anyway, the upshot is that I’m building a simple GUI frontend to it. It turns out that the interpreter API is actually really easy to work with – it only took me about half an hour to hack together a basic working frontend (after some… minor issues with Java’s IO API)
So far this isn’t really in a state that other people can use it – no proper buildscript, the GUI frontend is hacked together in the interface designer and doesn’t handle resizing properly at all (so is probably broken on any resolution but mine). This is more of a “If you want to look at the code and see how to do it” than anything else. It’s available in my misc hg repository.
A particular reason you might want to look at the code is that it uses QT Jambi rather than Swing, so if you want a Swing version you’ll have to write it yourself and might find this a useful starting point. Why? Well, two reasons. Firstly, I like the results and API of QT better than Swing’s. Secondly, Swing doesn’t work on my home PC so it would be pretty pointless for me to use it.
I’ve decided to start a new personal project, and I’m going to make it open source from day one. The project is called JTypeBuilder and is hosted at Google Code and released under an apache 2.0 license.
The basic idea is that it is used for generating data models and producing an awful lot of associated boiler plate code. It produces immutable classes for representing the data, mutable classes for generating the immutable ones and methods for passing back and forth between them. The immutable classes all have the obvious equals and hash code implementations, as well as a toString method which produces a JSON like representation of the class.
It currently just consists of a couple freemarker templates and some simple wrapper code for them. When I get around to it I’ll add a parser and command line interface for nice representation of the data models.
I have vague intentions of using this for some sort of simple ORM package. Another possibility is using it as part of a compiler backend for targeting the JVM – it can be used to generate the data types. All of this is in the future though – right now it’s simply a tool for reducing boiler plate code (and a fairly incomplete one at that).
Update: Phew. That was a succesful day. The parser and code generator now work, and are hooked together with an extremely rudimentary command line interface (it’s little more than a proof of concept). Still to do are improvements to the interface and customisability, as well as general improvements to code generation and parsing. Nonetheless, there is now a working tool there. Yay.
Actually, come to think of it, the biggest thing that needs fixing at the moment is the build.xml. It’s a really shocking piece of spaghetti XML put together with the intent of having something working quickly rather than actually producing a portable build script… Lots of hard coded paths.