jump to navigation

Reflective parameter names in Java 6 May 8, 2006

Posted by James Webster in : java , add a comment

Update: Paul has summarized the conversation about this issue but disappointingly it looks like the Java 6 team may be dropping this feature. It is a great shame that Java is becoming less and less willing to evolve, especially when the opposite is needed to compete against C#/.Net, Python, Ruby et al. Aside from an arguably broken implementation of generics, what did Java 1.5 bring to the table that C# 1.0’s syntax didn’t already have? (Yes, there is more to the platform choice than language syntax but that’s another conversation) Don Box is acutely aware of Ruby’s growing mind share and the reality that it has already started to take market share from the incumbents. Hopefully the Java 6 team will reconsider their decision.

My colleague Paul Hammant is asking about how we would like reflective access to parameter names to work (if it is indeed implemented) in Mustang.

He asks whether this should be enabled via an annotation or via a javac compiler flag. Via annotations feels like the right way to me (compiler flags are SOOOOO ’90s) but preferably with a way to enable parameter name access for a whole class/package/package hierarchy with the placement of a single annotation in an appropriate location. I am presuming Java 5 annotations have a similar mechanism to C# AssemblyInfo.cs and its behaviour with .Net attributes.

In addition to the possible uses that Paul defines; IDE clues, interface definitions for remoting/web services and AOP frameworks; I wonder whether this feature, inconjunction with an AOP framework, might allow a way to introduce keyword arguments with defaults, in a similar fashion to Python and Ruby?

In what other ways might this feature be potentially useful?

Java 5 syntax tricks to keep you DRY May 2, 2006

Posted by James Webster in : java , 7 comments

Update: I have changed the example a bit…

Which do you think is more readable; this…

someMethod(23, new String[]{"one", "two", "three"}, 42);

…or this…

someMethod(23, array("one", "two", "three"), 42);

The latter can be achieved in Java 5 with the following method leveraging both varargs and generics;

<T> T[] array(T... objects) {
    return objects;
}

I’m finding it useful to help maintain DRYness as the type of the array is stated once rather than twice. Of course, the array argument could be shifted to the last argument and varargs used on the method being called (if it can be implemented in Java 5). Its impossible to completely remove this sort of duplication in Java but not impossible to remove it from statically typed languages altogether. Have a look at Boo, a Python-esque language that targets .Net and Mono and supports type inference.

My examples were originally…
String[] arrayOfStrings = new String[]{"one", "two", "three"};
and
String[] arrayOfStrings = array("one", "two", "three");

As Brandon correctly identifies in the comments, the following is syntactically valid prior to Java 1.5 anyway…
String[] arrayOfStrings = {"one", "two", "three"};

A little bit of Spring, makes your code Sing! January 11, 2006

Posted by James Webster in : software, java, development , add a comment

Although I know it is EXTREMELY FREAKING UNCOOL to be using Spring and Java!, I feel its worth commenting on the announcement of the availability of Spring 2.0 milestone 1. We make extensive use of Spring at the day job, and feel it has been a key contributor to our extremely high code coverage, and the promotion of the ravioli code pattern; although some are of the opinion that ravioli code is an anti-pattern, I prefer smaller pieces loosely joined over the alternative.

I’m particularly keen on this bullet point:

Asynchronous JMS facilities enabling message-driven POJOs

Part of our system’s architecture involves POJOs receiving asynchronous messages via JMS. Until now Spring Remoting only supported JMS on the producer-side, not on the consumer, and we rolled our own message consumer (which is easy enough to do to be fair). I’m aware of Lingo, a complete JMS plugin for Spring, but at the moment it only supports JMS 1.1.4, no good if you are constrained to Weblogic 8.1 and JMS 1.0.2. A brief look at the code for Spring 2.0 shows that they are already building support for both versions of the spec.

It looks like the Spring team is also making an effort to streamline the XML grammar for configuring bean factories, which makes me happier… but I wonder if they would consider a YAML markup syntax?