lixo.org

I don’t know exactly where to post this to get the most attention from the JCP, so I just thought I would put it on my blog and ask the readers to kindly link it appropriately so it reaches the right pairs of eyes. Apologies if this post sounds more like a rant; in some respects, it is.

I’ll tell you what I really, really need from a future version of Java. This is where I’m coming from: I’m going to be using a language where I have to spoonfeed the compiler by declaring the types of my variables, parameters, methods, collections (with the addition of generics, even more than that), and sometimes I want to do some whacky dynamic programming with proxies, CGlib or just good old-fashioned wrestling with the bytecode in a pool of mud.

In those cases, I want to be able to isolate the dynamic whackiness as much as possible from the rest of my “sane” code. I want to make my code read as nicely as possible, given the constraints and inherent line-noise of the language I chose (or had to) to use, and last but not least, when I rename something, I want every single last one of the references to be changed automatically for me, and I don’t want to even consider the slight possibility of having to dig around some XML file or JMock test to finish renaming what the IDE couldn’t find.

I want extended static reflection capabilities: when I tell Spring that every URI that starts with /something needs to go to SomethingController.doSomething(String), I don’t want to give it a method name, I want to give it a reference to the actual method. Likewise, when using JMock I want to write something resembling:

mock.expects(once()).method(Foo.class.instanceMethods.bar(String.class));

instead of:

mock.expects(once()).method("bar").with(isA(String.class));

Even though the former takes a bit more typing, that call to doSomething(String) is something IDEs can work out from the AST without any fiddly string search-and-replace operation.

This feature does not change the syntax of the language (doSomething() would be a call to a method inside some instanceMethods field belonging to Class) and does not introduce any incompatibilities I can think of.

So, why not?

At my current project, we have a good definition of what the real data in the system will look like, since the first few releases are basically migration with the addition of some new features.

But, a couple of weeks ago, something started happening to the test code: instead of creating a place like ‘France’ and a non-place word that goes with it, like ’skiing’ - which is something you’d be likely to see in the production database, people were choosing their test data based on wacky and unrelated concepts. Places like ‘plate’ and non-places like ‘cheese’ were popping up left ,right and centre. Converting an object from ‘cheese’ to ‘pizza’ seemed quite odd when said out loud, but made sense in the code, just as converting a legacy object to the new domain model, after some validation and filtering did. But it’s a much shorter and visual sentence.

What happens when you do such a thing? Your test code looks like something you’d never put in production. No production code would have variables like ‘cheese’, ‘bacon’ or ’sausages’. But test code can afford that, as long as it expresses the behaviour you’re trying to test clearly, and weird variable names or test data don’t detract from that.

Plus, the hilarity that ensues when you get your customer talking about the stories in half-breakfast, half-business terms is enough to bring the team morale up a bit.

Any experiences on that? I’d like to hear’em!

In the 1890s, a guy named George Stratton decided to build a pair of glasses that made the world upside down. He wanted to explore the effect of presenting the retina of our eye with an upright image, since the image that it sees is inverted.

The conclusion of his experiments demonstrated that, after some hours of adaptation (and probably making everyone in the room collapse in laughter seeing him trying to drink a cup of tea), most things he saw looked normal using those glasses and, upon closer inspection, looked weird again. Since then, tens of scientific experiments have based on his conclusions to find out about other interesting and wacky situations our brains can adapt and readapt to.

Today, I opened IntelliJ again, after about 3 months of heavy Eclipse usage. Trying to use the keyboard shortcuts felt like taking those glasses off.