Paul Hammant's Blog: Parameter names for Java 6 (Mustang) question

Interesting things from the Java 6 committee

One of the features forthcoming in Java 6 / Mustang is "Reflective access to parameter names".  Read about it in http://jcp.org/aboutJava/communityprocess/edr/jsr270 It is a target of opportunity and is 75% of the way down the page (feature/anchor #402).

The JSR 270 / Mustang committee team is keen on the feature but concerned about a couple of points. I've permission from the spec lead to make some element of the quandary public.

Marking of public parameter names

Should this be explicit with an annotation above the constructor/method in question -

  @PublishParameterNames
  public void doSomething(String theThingTodo) {
    // etc 
  }

Or a -g option on javac ( see http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html ). It could be an extra one, or folded into one of the existing, including being a default option (would happen in the absence of a -g option).  -g, of course, is normally used to bake in debug information to class files.  If the "full debug" option were the only way, then it would mean considerable bloat of class files.  A new -g option could be for param names only, and then only for public/protected methods and constructors.

Which is right?  Would param name access be required on a wholesale basis, or selectively set wherever there were method/constructor/class marked by @PublishParameterNames (or similar)?

Access to parameter names.

A method similar to 'getParameterNames()' would most likely be added to Constructor and Method from the reflection API.  If the information were available, the names could be accessed like so -

  Method method = aClass.getMethod("doSomething", new Object[0]);
  String[] paramName = method.getParameterNames();

Its entirely new, and does not complicate the classic understanding of method signature.
A real question is, would developers start to hard code the parameter names into shipping applications and require that parameter to go unchanged in future versions of Java.  Microsoft seem happy to break compatibility over time (refer Win16->Win32, .Net 1.1->2.0), but Sun are reluctant to do so.

If a method today has a signature defined by ...

•   name
•   parameter types

... but not by ...

•   exceptions
•   return type (yes true)

... should adding 'parameter names' be considered part of the method signature or not?

If someone were to bake it into an application, and that worked on JDK 1.6.0 but not 1.6.1 whose fault would that be?

  String[] paramNames = method.getParameterNames();
  for (int i = 0; i < params.length; i++) {
    if (params[i].equals("theThingTodo") {
      // do something special
    }
  }

Is there a 'caveat emptor' element to param names (should you choose to bake them into an application), or would 'method signature' explicitly change?

Who would use this feature?

1) IDE makers

Here is a screen shot of IDEA operating without knowledge of JUnit's parameter names...



And here with access to JUnit's parameter names.  This is simulated for now by attaching Junit src for IDEA to process for extra debug capability and param name access, which is impractical for too many third party jars...


Interestingly, IDEs everywhere could benefit from accessible parameter names, but not for the classes that come the JDK.  Why? source ships with the JDK anyway, and IDEs as you can see above have no problem accessing that.

2) Remoting technologies

Of greatest applicability are Web Services frameworks that automatically export WSDL for the web methods exposed.

3) AOP frameworks and their usual targets.

These technologies intercept method calls.  Access to parameter names could be a boon.

4) Others?

I'd be interested in hearing about other uses for param names not caught by the vague AOP line. For example, would a transparent persistence tier use it?  A DI framework probably would, but what else?

---

---

Published

March 20^th, 2006

Reads:

Tags

• Paranamer 2