In Love with Java5

Rolling your own Java

In Shai's
"Java5 language changes were a bad idea", he suggests just that.

A coupla of years ago, before i starting tooling up (starting with IntelliJ, then using Eclipse, and nowadays Netbeans), i used vi. You're right RMS, it's not a sin to use vi, it's a penance - in order to find salvation with Java IDEs.

So there were a few things i really wanted in the language, for my personal convenience. So i created a bash script with some greps, that did the following to my Java2 code on that project.

• where i found curly brackets, i inserted new Object[], and where i found an underscore following a comma, i converted to a string, eg. logger.info({"the int value is", _i}) ended up as logger.info(new Object[] {"the int value is", ""+ i}), ie. varargs and autoboxing.
• less trivially, where i found foreach, i inserted for (Iterator it...).
• where i found util.putTheDogInside(), i changed that to Util.getInstance().putTheDogInside() (because i don't believe in a class full of static methods). With Java5 you can achieve the same with static importing, innit.

Maybe i did some more stuff, but i can't remember. Anyways, as you can see, i was wanting Java5 very much!

-->
Love is... Java5

Once i started using Java5, i actually found it impossible to revert to Java2. And believe me i tried. I know it's a career limiting move, but that doesn't change a thing. I just couldn't imagine living without my new found love.

I must say, i would like a type alias for generic types, because they tend to get very hairy, very quickly. (See this bug.) One can achieve this at least with interfaces, by extending them emptily. Similarly with classes, although then we have to duplicate the constructors.

For some or other reason, as much as i love enums and annotations, i wish they were more like regular objects,
which can be extended and what-not. I wish the annotation declaration was a notation to create a new object of the given type, and set its properties. And at times, i've wished that the enum notation was
short-hand notation for object construction, that could be reused for other wierd and wonderful things. One is never satisfied with enough, innit!

Look, No Strings!

At the maximal risk of being boring and repetitive (because i am being
repetitive, mostly to avoid doing some constructive work right now), in addition to type aliases, what i would love to see in the language, before anything else like closures or whatever, is for references to fields, methods and properties to be first class citizens of the language, so as to be toolable (eg. prompting, autocompletion and not least, refactoring). So one could have code like

setNameFromField(saveButton, MyClass%saveButton);
createListenerFromMethod(saveButton, MyClass#saveActionPerformed);
bindEnablerFromPropertyDescriptor(saveButton, MyClass:saveButtonEnabled); 

where MyClass%saveButton gets at the Field named "saveButton", MyClass#saveActionPerformed, the Method named "saveActionPerformed," and MyClass:saveButtonEnabled, the PropertyDescriptor named "saveButtonEnabled" ie. there are methods isSaveButtonEnabled() and setSaveButtonEnabled(boolean) in MyClass.

Into Tools

I, myself and me personally, would be happy enough if just Netbeans supported the above as a short-hand notation, ie. in its editor, and refactorings. Because i use Netbeans. I wish i had a clue, and the time to write such a plugin. Actually i do (have the time), so i will :) as soon as i get some clues, if not before ;)

Which does raise the point, that perhaps conveniences should be built into tools (first), rather than into the language itself. If for no other reason, than to see what traction they can accrue, if any, before incorporating them into the language, or at least into other tools. I guess the risk is that the language might become "fragmented" between the (three) different IDEs, if they were to support differing short-hand notations. Having said that, there is no stopping people customising their own favourite IDE, for their own personal convenience and productivity, as i would wish to do, if i had a clue how.

No Name Brand

An alternative to the above, is binding by convention, eg. if one has a component saveButton, then we look for an event listener method and property with "conventional" names, eg. "saveButtonActionPerformed" and "saveButtonEnabled." But that's hardly toolable, eg. no IDE verification. Neither is using string references to refer to the method and property.

Mmmm, Annotations

Arguably the best approach is using annotations, and testing classes to reduce fragility, by inspecting the annotations, and verifying them using reflection. In particular, we should test that names in the annotations are valid, eg. if we have an annotation with enabledMethod="isSaveButtonEnabled", then
the method isSaveButtonEnabled() should actually exist, and not have been renamed in a refactoring operation. Of course, since we don't have IDE verification (or auto-completion), it's easy to misspell in the first case, D'oh!

Post Scripts

Ps. On the non-Java personal side, i'm sitting in my house in Cape Town, for the first time in 5 months, preparing to move out of it. As the Russians say, "Moving house is an equivalent disaster to your house burning down, twice!"

I guess i'm gonna miss this house, particularly the space - my new place is smaller, but nicer. I'm not gonna miss the windy weather here (on Cape Point) - which hinders one's cycling plans. Yes I'm gonna love my new place, which is in the "wine lands," ie. inland a bit, a place called Durbanville actually. When i'm not Sideways at a wine farm, or cycling past vineyards and "cows in the field," you'll find me... right here! And that's even when i'm at my friend's coffee shop in the mall across the road, where i'll be pulling 3Gs on a regular basis. Mmmm, bottomless coffee, mmmm, wireless Java.