Is there anything wrong with having a (custom) getId method on a Java object used in JRuby?

I'm a big fan of concise method names, so when our codebase has something like:

Account.getAccountId();

I like to add an alias so that I can just do:

Account.getId();

However, I've heard ... murmurs from elsewhere in my company about how this might be problematic, because the getId I define will interfere with a built-in getId that all Java objects have, or something like that. Also we use JRuby to reference our old Java classes, so the issue might have something to do with a built-in Ruby getId method too.

Still, I'm not entirely convinced that there is a problem (and I really like my short method names). So, does anyone out there know whether there are problems with defining getId methods (either in Java or JRuby), and if so what are they and can they be worked around?

EDIT: It seems from the responses so far (and what I already knew about Java) that the issue can't be with some core Java getId functionality (as there is none). So really this question is for JRuby people; if the getId "conflict开发者_JS百科" is coming from anywhere, it's got to be from JRuby stuff.

However, I've heard ... murmurs from elsewhere in my company about how this might be problematic, because the getId I define will interfere with a built-in getId that all Java objects have, or something like that.

The java.lang.Object is the root of the class hierarchy. Every class has Object as a superclass. All objects, including arrays, implement the methods of this class.

But Object doesn't have any getId a method. And so do all Java objects.

I tend to prefer readability over conciceness. To me getAccountId is clearer than getId

Given the 2 lines below it's much clearer that foo is an account object. (though I wouldn't really call an object foo)

foo.getId();
foo.getAccountId();

edit, the java class Object has no method getId(). I don't know ruby so you'll have to rely on others to let you know about that.

The problem I would see is if on an object a getId method (or similar method name) were later added that conflicted with your alias, it would break code. When someone has an object, adding a new method should be a non-breaking change (serialization aside), but in fact they would be breaking your code because of some aliasing that you did.

So the problem isn't that it conflicts with a getId that is defined for all objects, but that it could conflict with a method that will be added later to the same class. One way around this might be to make a wrapper class that has the short method names, so that the delegation is clear and static and if the method name is added, it might create confusion, but it would be more containable.