Paul Hammant's Blog: Announcing Paranamer; an open source answer to the dropping of parameter name access from Java6
Java 6 has shipped of course. Without a feature that the
committee overseeing it thought would be good: Parameter name access.
The committee had a design that there was consensus for, but Sun suggested there was no more time to finish it a few months before shipping. Sun, themselves, were also against the availability of parameter names in the way that other members of the committee had settled on. Instead they wanted some annotation above the methods that one wanted to have parameter name access for. I for one, felt that was a huge cost and illustrated that we had learned nothing from the terseness lessons from the Ruby crowd. Ruby and Rails are making massive inroads into enterprise Java and .Net development from what I hear, for multiple reasons of course.
Anyway, a -g compiler option would have been far better. Sun needed to get over the worry that backwards compatibility needs to be assured forever. If someone wants to hardcode say getMethodByParameterNames("addTwoNumbers", "numOne", "nunTwo") and the later release of that dependent number-adding.jar might spell fix nunTwo to numTwo, then on their own head be it. The potential changing of the parameter names was the big driver for the annotation design. To me a Java method signature is forever method name + arg types, and should never be expanded to include parameter names, which was not explicitly stated, but is implicit if the parameter names are immutable.
So enterhttp://paranamer.codehaus.org ParaNamer (was
supposed to be Paranamer, but the excellent Codehaus admin Ben Walding
capitalized the second word). It adds parameter name access for
Java 1.4+
It is really small and the hope is that it delivers something that may be useful to many apps trying to compete in the Ruby on Rails age. If Java7 does the right thing, then Paranamer does not need to exist from then on. If Java 7 does the wrong thing ( @PublicParameterNames above each method in the source ) then Paranamer will continue to exist. Incidentally, we allow for a doclet tag called 'PreviousParameterNames' for those really interested in hitting the nunTwo/numTwo case above in a backwards compatible way.
We wrote the first version as a knee-jerk to the happenings on the Java6 committee. It usedhttp://qdox.codehaus.org Qdox (an excellent Joe Walnes
product from his productive years at ThoughtWorks before Google gobbled
him up ;) to run thru the source after compilation, but before Jarring
to make more info to shove in the jar before subsequent use. More
recently, VRaptors' Guilherme Silveira baked in a second implementation that uses ASM
at run time. Its what the Spring boys do too for getting of parameter
names. So at runtime Paranamer either depends on ASM or on
nothing depending one what you which mode of operation you want.
Feel free to use and contribute patches back. Mauro Talevi, just cut release candidate 1.
The committee had a design that there was consensus for, but Sun suggested there was no more time to finish it a few months before shipping. Sun, themselves, were also against the availability of parameter names in the way that other members of the committee had settled on. Instead they wanted some annotation above the methods that one wanted to have parameter name access for. I for one, felt that was a huge cost and illustrated that we had learned nothing from the terseness lessons from the Ruby crowd. Ruby and Rails are making massive inroads into enterprise Java and .Net development from what I hear, for multiple reasons of course.
Anyway, a -g compiler option would have been far better. Sun needed to get over the worry that backwards compatibility needs to be assured forever. If someone wants to hardcode say getMethodByParameterNames("addTwoNumbers", "numOne", "nunTwo") and the later release of that dependent number-adding.jar might spell fix nunTwo to numTwo, then on their own head be it. The potential changing of the parameter names was the big driver for the annotation design. To me a Java method signature is forever method name + arg types, and should never be expanded to include parameter names, which was not explicitly stated, but is implicit if the parameter names are immutable.
So enter
It is really small and the hope is that it delivers something that may be useful to many apps trying to compete in the Ruby on Rails age. If Java7 does the right thing, then Paranamer does not need to exist from then on. If Java 7 does the wrong thing ( @PublicParameterNames above each method in the source ) then Paranamer will continue to exist. Incidentally, we allow for a doclet tag called 'PreviousParameterNames' for those really interested in hitting the nunTwo/numTwo case above in a backwards compatible way.
We wrote the first version as a knee-jerk to the happenings on the Java6 committee. It used
Feel free to use and contribute patches back. Mauro Talevi, just cut release candidate 1.