Getting a method name without a String representation of the method name
I am doing a mapping from fields in a specific file to getters in a POJO that I want associated. The fields in the file should be independent of the fields in the POJO. I should be able to change my file or my POJO and only have to maintain the mapping in between.
Once the mapping is complete, I would just run my code through reflection and auto populate the fields from my POJOs getters. The problem that arises is that I cannot get the Java method name without already having it in a String format, ie
Class.class.getMethod(nameAsString).
Well this now means that I have to maintain the string representation in my mapping of my method names to the POJO. So if I were to refactor my code, I wouldn't see that change, and it could go unnoticed or ignored. In my opinion it is an unnecessary limitation and increases a high level of unnecessary coupling.
Does anyone know how to retrieve the method names, such as Class.getField.getName(), or any other patterns any one else has in respect to this issue? Thanks.
# 1
Both Method and Field implement an interface called Member, which defines a getName method. But I don't see how that will help you avoid having to maintain the method names externally
How are you planning to actually map things without method names? How will your code know where a particular field from the file is being mapped to? Having to keep track of a method name is hardly tight coupling, if you ask me. I'm working on something similar at the moment, and I'm just using property names, and resolving them to method names at runtime, so the serialized data is basically a name-value pair eg:
<property name="userName">
<value>John C. Random</value>
</property>
and "username" is resolved to either getUserName or setUserName at runtime depending on which way the mapping is going. Not really that tightly coupled. You mentioned refactoring, but how often do you really refactor a property name to something else? Having said that, I've also got a couple of other strategies for mapping property names to methods kicking about, either using Java Annotations (you need to be on Java5 or above to use them), a metadata mapping file (a la Hibernate, CMP et al) or I'm also planning on driving metadata from an XSD, which can also be used to generate the bean classes themselves, using xbeans. But far-and-away the simplest and most transparent is to just rely on the method names not changing. If you really envisage problems, there's a library called [url=http://dozer.sourceforge.net/documentation/mapbackedproperty.html]dozer[/url] which will map beans to other beans, which might help overcome that problem, or might not.
But I'd just rely on maintaining the method names as properties. Look at the JavaBeans tutorial, in particular the section on BeanInfo, for how to map property names ("userName) to methods ("getUserName").
# 2
I was hoping for some convetion, akin to Class, for maintaining the mapping. I.e. Class.class.getName(), will give me the name of the class at compile time. So like this, I was hoping to find some way of performing. Class.MethodName.getName(), with this convention the mapping would follow as such:
String FIELD_NAME = "name of field in external resource";
Class POJO {
private String field;
String getField() { return field; }
}
Map<String, String> mapping = new HashMap<String, String>();
mapping.put(FIELD_NAME, POJO.getField.getName());
I realize this method can't take arguments into account, but it shouldn't matter as all you need is the name, not the method, but how Java would resolve that name is unknown to me. But this is really what I was trying to get at.
# 3
> I was hoping for some convetion, akin to Class, for
> maintaining the mapping. I.e. Class.class.getName(),
> will give me the name of the class at compile time.
> So like this, I was hoping to find some way of
> performing. Class.MethodName.getName(), with this
> convention the mapping would follow as such:
>
>
> String FIELD_NAME = "name of field in external
> resource";
>
>Class POJO {
>private String field;
>String getField() { return field; }
> }
>
> Map<String, String> mapping = new HashMap<String,
> String>();
> mapping.put(FIELD_NAME,
> POJO.getField.getName());
>
> I realize this method can't take arguments into
> account, but it shouldn't matter as all you need is
> the name, not the method, but how Java would resolve
> that name is unknown to me. But this is really what
> I was trying to get at.
Ah I get you. No, methods don't provide that, it's come up before. It wouldn't be practical anyway, since you can feasibly have several methods with the same name in a class. Just go with property names matching field names, I'm betting the refactoring of the names won't happen nearly as often as you suspect. If it does come up, you can always write a simple tool that will refactor the names in mapping files along the way. It's only text, after all. Incidentally, if these files are XML, you might well be better off using something like Apache Digester to do the heavy lifting, rather than roll it yourself. Whenever I come up against some niggly thing like this, I reach straight for Jakarta Commons to see if it's already been done
# 4
But, with respect to the name, I don't care if the method is overloaded. I just want the name. Again, I realize if Java were to do this, it would be nigh unto impossible with the convention I have written, as it wouldn't know which name to choose, if it were to treat all methods as objects, but there must be some way of retrieving the name (even if it is through a modification of the JVM through an enhancement). like POJO.getField(new Object[]{}).getName();
Either way it doesn't seem too out there, nor too trivial. I should be able to map my fields to my getters w/o having to type the name as a string, but as it seems that would require an enhancement to java. Thanks for your help.
# 5
> But, with respect to the name, I don't care if the
> method is overloaded. I just want the name. Again,
> I realize if Java were to do this, it would be nigh
> unto impossible with the convention I have written,
> as it wouldn't know which name to choose, if it were
> to treat all methods as objects, but there must be
> some way of retrieving the name (even if it is
> through a modification of the JVM through an
> enhancement). like > POJO.getField(new Object[]{}).getName();
>
>
> Either way it doesn't seem too out there, nor too
> trivial. I should be able to map my fields to my
> getters w/o having to type the name as a string, but
> as it seems that would require an enhancement to
> java. Thanks for your help.
Your fields in the file must have some sort of identifier. Just have the method names derived from that, and there's no need for modified JVMs and the like, which would of course instantly ruin the portability of your code. Consider your proposal:
POJO.getField(new Object[]{}).getName();
How would the compiler know you are accessing a method object there, and not merely trying to invoke a static method on POJO? I suppose a "methods" operator akin to the "class" operator could come into play
POHO.methods.getField(Object[].class).getName();
But that's quite unweildy, and introduces another reserved word - methods - that I guarantee will break a ton of code that's already out there. If you know the parameter and return types, I suppose you could examine the result of POJO.class.getDeclaredMethods, and match by parameter type, but that relies upon no 2 methods accepting the same parameters, and since Object.equals() already accepts an Object, Object.hashCode() already returns an int and Object.toString() already returns a String, you're already limited. Whatever solution you've got in your head, just having the field name in the file match up to property names is far-and-away the simplest and most robust solution, not to mention it can actually be done! Everyone else gets by with that, and it saves you having to document that (for example) field TITLE in your file currently maps to setUserSalutation in your bean class, maintain that documentation, ensure that people know it exists, not to mention the extra mapping code to be written
# 6
I completely agree that the implementation would not be trivial, and that the design would take much more time and thought that couple of forum posts could provide, but I would still push that the name of the methods of a class should be accessible at compile time, as opposed to only run time. Java knows the names of classes/memberes/methods at compile time (otherwise it wouldn't compile), the only challenge is to make all that information accessible along with it's metadata (in a manner that is clean and concise), at compile time to the programmer.But again thank you for your additional insight into the complexities that lie within the concept. I do appreciate the time you've taken to reply to my posts.
Message was edited by:
SavedLinuXgeeK
# 7
> I completely agree that the implementation would not
> be trivial, and that the design would take much more
> time and thought that couple of forum posts could
> provide, but I would still push that the name of the
> methods of a class should be accessible at compile
> time, as opposed to only run time. Java knows the
> names of classes/memberes/methods at compile time
> (otherwise it wouldn't compile), the only challenge
> is to make all that information accessible along with
> it's metadata (in a manner that is clean and
> concise), at compile time to the programmer.
LinuXgeeK
I've often wished I could statically get hold of a Method object, too. But never in a situation that could be resolved some other way. By the sounds of what you're doing, it's a bit of a sledgehammer and walnut situation, anwyay, and there are a multitude of other reasons (outlined above) not to do it, even if you could
> But
> again thank you for your additional insight into the
> complexities that lie within the concept. I do
> appreciate the time you've taken to reply to my
> posts.
No problem at all. It's good to have an interesting question to ponder, and it's made me put into words a few things I've always had at the back of my mind, but never really thought about.
These files you're mapping to beans - are they XML? There are a bunch of tools available for working like that, that might make life easier for you
# 8
No, I'm not mapping XML files. The file I am mapping against is a legacy PDF (it may be stored via xml, i'm not sure) so I don't have much control over the external resource that I'm mapping to.
# 9
Have a look at java.beans.Introspector and friends. In fact have a look at java.beans.*. Also java.beans.XMLEncoder/Decoder.
ejpa at 2007-7-12 9:51:28 >
# 10
I tried to solve this problem with enum.Here is how it looked: http://www.jfrog.org/sites/jfrog-reflect/1.0/But I'm not really happy with the verbosity.Can you tell me if you will like that more: http://www.jfrog.org/wiki/index.php/Fred:Abstract_EnumThanks.
