Java 6 parameter names - distilled thinking

Its been over a month since I posed the parameter names question. Here's the wisdom from those that emailed and wrote their own blog articles.

I was hoping that people would push for a compiler option (settling for that as the default compiler option) and agree that there was a caveat emptor aspect to relying on parameter names.


James Webster (fellow ThoughtWorker) likes the fact that a scripting lang could leverage it and prefers the attribute/annotation style of marking one or more methods up as having public param names. Read it on James' blog

Peter Royal (unprompted) thought the same as me. Link to Pete's blog entry

Eugene Kaganovich emailed me :

I think you may be interested in the OOWeb project at . They try to map URL queries into java methods. One of the issues that they've been struggling with is precisely the unavailability of method parameter names in Java reflection. Specifically, see the sections and in the tutorial.
Eugene is not involved in that project, just watches it.

Zhong Yu emails :

>Who would use this feature?

you can count on one thing for sure: web MVC frameworks:)
mapping between HTTP parameters and method parameters
can now be 'automatic', a web framework can appear to be
really simple and elegant.

>Marking of public parameter names

I'd prefer to have the names in class file by default, without any
annotation or compiler flag. sizes of jar files are hardly a concern those days.

if annotation is used, note that normally such methods are annotated
already by some other annotation (say @WebService) which probably depends
on the existence of parameters names to function at all. Therefore an
annotation for annotation may be sensible:

public @interface WebService

Axel Rauschmayer emails:

- Advantages for Java: I would love *Java* to have keyword arguments. Languages that do have it (such as Smalltalk and Python) lead to source code that can mostly be read without ever consulting documentation. The first step towards keyword arguments would be always enabling runtime parameter names and displaying them in the source code. Later keyword arguments could syntactically become part of the language. Syntactically, reusing the label syntax looks good, fits into the current syntax style, and might work parser-wise (whereas the equals operator ---as used in Python ---clearly would not work): For example:

mySphere.move(x: 3, y: 5, z: 33);

- Method signatures: The most compatible solution would be to leave signatures as is. Parameter names would just induce an order on keyword arguments. I don't see any real drawbacks with that solution while implementing it is easy and it mostly involves the compiler.

- Advantages for scripting languages: I haven't seen scripting languages mentioned in the post, but these would also profit from this feature. Another example comes from a project of mine: I use normal methods to define operations that the end user can perform. Currently, I have to annotate each parameter with its name for even the most basic parameter entry dialog to make sense. With runtime parameter names that need would go away. Well, OK, this example is a bit exotic, but in general, scripting languages will profit.

David McCuistion emails ..

I'd love this feature for exactly the uses you talk about: DI and web services.  But instead of web services in the concrete sense, I'd like to use them for auto-binding HTTPServletRequest parameters to POJO methods.  Currently, I use the javax.jws.WebParam annotation but it's ugly:

public void myMethod(@WebParam(name="userId") String id, @WebParam(name="firstName") String firstName, @WebParam(name="lastName") String lastName, @WebParam("middleInitial") String middleInitial) { ... }

As you can see, it's usually redundant and ugly as sin.

Also, I'd vote for making the parameter names available all the time, not requiring the use of @PublishParameterNames or -g at compile time.  This would make it easy POJO frameworks to work more easily with end-developers' code without requiring them to scar up their code with more annotations or bloat their bytecode with debug info.

With parameter names available for reflection, it could allow everyone to start thinking about named parameter method calls (instead of positional), like so:

myObject.myMethod(id: "joep", firstName: "Joe", lastName: "Public");
  // middleInitial passed in as null

So: I like it very much especially if it is available on any method without annotations or debug compilation.


So there's fairly mixed opinion.  The Java 6 committee is leaning in the direction of dropping this feature from Java 6 and asking the Java 7 team to reconsider the options. The Java 6 team would leave some notes/recommendations for the 7 lot I guess.

From those that counsel caution within the Java 6 team, the key fear is that developers may ship tools that expect the parameter names to go unchanged between releases. This mostly counts the JDK, which Sun characterizes, but also count third-party tools as, say Hibernate, changing its param names would lead to bad karma for Java were scripts/meta data/code to be shipped that relied on its param names.

The nub of contention is whether the community would heed warnings to not hard code parameter names and ship releases of software (internal to a company or external to the community).  Or if they did would they not complain when a small percentage of parameter names changes between releases.  Incidentally - never changes parameter names once set was not an option.

Would a annotation style be discouraging enough for the hard-coders of parameter names?  Or would it cripple a key feature?

I really wanted to see this in Java 6 - I hope there's still time to get it in, not withstanding the lack of unanimity on the committee.

Is this worth a bigger public debate? Can the Java community promise to be forgiving in the event that parameter names change and not consider it part of an eternal method signature?


May 6th, 2006