I posted my first question yesterday, a real question that I didn’t know the answer to, that was relevant to my work. I’m trying to shoehorn Java into a new shoe, for a project where dynamic languages would be a more natural fit.
Grails has shown Java could be competitive though, at least as an easy to use “convention-over-configuration” web framework. In fact, I first wanted to use Groovy, but team resistance made me abandon that track.
Anyway, I thought I’d give it a try. I started with a big properties file, moved into a hashmap (a friendly co-worker who didn’t know what I was doing suggested hashmaps were almost never the answer) and then though about static fields. And then static inner classes. This would give the huge benefit of IDE discoverable configuration, but it would be a maintenance nightmare. A hierarchy of potentially hundreds of properties over dozens of classes, all in one file — being edited by 20 people.
I found a way to do it, but the compiler was throwing up warnings left and right.
“The static field Foo.bar shoudl be accessed in a static way”
But it compiled and it worked. I knew my team mates would never stand for it. And half of them wouldn’t even understand why it was being done that way. The other half would say that it was the wrong way to do it, but not know a right way that I could be happy with. So that wasn’t maintainable either.
I knew it was possible, but I knew the compiler didn’t like it. I thought it was a limitation of Java (probably deliberate–in the same way every bug ends up being ‘the way I meant to code it’), but I was determined to beat the system. I wanted to know what the rationale for the error was, though I didn’t hope to get a decent answer. But I did.
Thanks to stack overflow and jon.