From freenode ##java:
10:13 < DRMacIver> cybereal: Oh, I figured out how to work around the Java type system to make my generators work. It requires a bit of a rearchitecture though.
10:13 < DRMacIver> It’s blatant and malicious evil I’m afraid. :)
10:13 < cybereal> That seems to be the way of things for you lately
No further work done on it at the moment, but that’s because I’m rethinking its architecture.
Rather than building a DSL, I think it’s much more sensible to use abstract Java classes as the templates, with the generated classes subclassing a user defined abstract class and the abstract methods and annotations defining which methods are going to be generated.
This will let me switch to a more APT centric approach. I’ll probably start using apt-jelly for this, as it works quite well with the existing freemarker based approach.
Warning: This post contains rant and is short on actual reasoned arguments.
There are a number of things that are often considered bad practice in Java. These include static imports, star imports, shadowing, omitting braces, notUsingReallyLongVariableNames, etc. Also, many Java developers object to features like first class functions, operator overloading and type inference, because they might ‘overcomplicate’ the language and cause people to produce unreadable code.
Given that this is a post about concision, I will now shorten the above rules into a single rule:
It is bad practice to do anything which might cause you to write less code.
“Oh.” says the (hypothetical – I don’t think anyone actually reads this blog) reader, “Another whiner who doesn’t like typing. Just use an IDE!”
This is not about typing. I know perfectly well that the IDE can do ‘typing inference’ (so to speak). This is about reading. Making your code more verbose does not make it more readable. In many cases it makes it less readable because you’re hiding the actually important stuff inside layers of crap. Further, even when all of it is relevant, expressing it in an overly verbose way makes it much harder to take in.
Even ignoring the functional programming argument, I think the Java community and conventions would gain a lot by losing their fear of terse code.
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.
I was looking at JGA earlier. Basically yet another instance of the JGreenspun pattern. I have my own implementation of the same sort of thing – JGA looks significantly better than mine frankly.
But, even with a nice terse syntax, the kind of shenanigans one has to go through to make it work are pretty horrible. Take a look at some of my code snippets if you don’t believe me (granted the snippets I had are not very terse, but due to heavy use of anonymous inner classes one is pretty stuck with using constructors, which with abundant generics quickly leads to some really horrible lines). Although you can get most (well, about 75%) of the functionality of a functional language like ML or Haskell into Java if you hammer enough, the result is fairly mindly blastingly horrible.
Shorter syntax for declaration of anonymous inner classes would certainly help a bit, but I don’t think it’s really going to be enough. I think that until closures come along to Java (and I mean proper BGGA style closures. Anonymous inner classes just aren’t going to cut it) I’m going to have to revert to the way of doing things that doesn’t involve too much greenspun. And/or defect to Scala completely.