Paul Hammant's Blog: Parameter names for Java 6 (Mustang) answer
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.
Respondents
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' blogPeter 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 http://ooweb.sourceforge.net/
. 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 http://ooweb.sourceforge.net/tutorial.html#forms and http://ooweb.sourceforge.net/tutorial.html#maps 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:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@PublishParameterNames
public @interface WebService
{
}
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:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@PublishParameterNames
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 ..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.
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.
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.
Summary
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?