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?