A message to Sun engineers: Please stop making my code ugly
Java has had the concept of beans and getters and setters for a long time. I thought we had all agreed that they work and clearly show intent. I felt annoyed when I saw the java.util.regex package appear in Java 1.4 with methods like matcher(CharSequence) and group(int), when they should have started respectively with create and get. I didn’t like so much the new Java 5 util.concurrent methods Executors.callable(Runnable), which should be prefixed with get or create.
I just now came across the new ProcessBuilder class in Java 5, with methods like redirectErrorStream(boolean) and environment() which should be a setter and a getter, respectively.
It’s harder and less pleasant for me to read my own code when using these classes. I hope Sun engineers will stop knowingly making Java code uglier in future releases.
August 30th, 2005 at 4:03 pm
Josh Bloch also suggests in ‘Effective Java’ that in general following conventions like JavaBeans is a good idea, but in some general-use APIs which are expected to get heavy use, it’s not a bad idea to make method names smaller. A typical case is teh Collections classes, which have methods like iterator() and next() rather than getIterator() and getNext(). After all, most likely somebody is typing these, and it’s no fun writing long method names always.
Sumit.
August 30th, 2005 at 4:40 pm
Hahaha! I agree. You don’t know the squirming I have to do when I get asked, “If encapsulation is so important, why can you access length directly from any array? and why doesn’t it come with a getter and setter”. :)
August 30th, 2005 at 8:12 pm
I agree. It feels dirty setting public variables from outside a class. It doesn’t feel quite as dirty to read them, although still somewhat dirty.
August 31st, 2005 at 1:08 am
actually I believe in many (but not all) methods like that are operations in the strict sense and not properties which means they don’t really have to follow the java beans standards.
also with BeanInfo classes - equally part of the spec - you don’t have to use getX/setX for some property X anyway.
August 31st, 2005 at 4:15 am
Sumit,
The problem is that “iterator” and “next” are not “properties”. The is/get/set convention is only applicable to properties. Nevertheless, I also don’t like seeing that built-in Java classes do not adhere to the naming conventions here and there. The first one I encountered was the Color.red, Color.green, … static variables which had to be Color.RED (Sun fixed this in 1.4) Also the classes/interfaces in the CORBA related packages are entirely against the conventions :-)
August 31st, 2005 at 9:32 am
In response to comment #4, if they are operations, why are their method names nouns? Operations are expressed using verbs in English.
August 31st, 2005 at 10:11 am
Typically you only want getters and setters to be very simple operations that do not change the object state beyond the attribute in question. I think that is the reason things like the Pattern#matcher method is named as it is - the java doc says: “Creates a matcher that will match the given input against this pattern.” You really don’t want something that takes a param and creates a new object to be called “getMatcher”. Also, the execute method should definitely not be a getter or setter: “Executes the given command at some time in the future. The command may execute in a new thread, in a pooled thread, or in the calling thread, at the discretion of the Executor implementation.” This is definitely not a case where you want something to be called setRunnable, as it is really doing a whole lot more work then just setting an attribute.
So following the JavaBean naming convetion makes sense on simple pojos, particularily ones that face your GUI, but methods that do then get/set more work should not follow the standard just to allow tools to work.
August 31st, 2005 at 10:16 am
Rob, it should be called createMatcher if it creates a matcher. I never said anything about an “execute method.” The method is
Executors.callable(Runnable)which simply creates a Callable instance which calls the Runnable and returns null, it doesn’t execute anything.September 2nd, 2005 at 1:29 am
> Daniel Hinojosa:
>Hahaha! I agree. You don’t know the squirming I have to do when I get asked, “If >encapsulation is so important, why can you access length directly from any array? >and why doesn’t it come with a getter and setter�. :)
Dont squirm just explain Arrays are stupid objects with no behaviour - just data.
October 29th, 2005 at 9:21 am
Good words, Keith. Let’s nip this in the bud: http://crazybob.org/2005/10/i-heart-getters-and-setters.html