afaik the spec says that for a boolean property the getEnabled() as well as the isEnabled() methods are valid. But we can make this clear... on http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html is the bean spec. There you can read:
8.3.2 Boolean properties
In addition, for boolean properties, we allow a getter method to match the pattern:
public boolean is<PropertyName>();
This "is<PropertyName>" method may be provided instead of a "get<PropertyName>" method, or it may be provided in addition to a "get<PropertyName>" method. In either case, if the "is<PropertyName>" method is present for a boolean property then we will use the "is<PropertyName>" method to read the property value.
An example boolean property might be:
public boolean isMarsupial();
public void setMarsupial(boolean m);
I am speaking from what I remember here, so it might need tests to be sure, but... what groovy does not is that if the parent class is providing an is-method, and you define a property of the same name, then Groovy will not overwrite the is-method, but generate an get-method.
From the runtime side we use the bean utils provided by the jdk, so if these utils follow the specification and a boolean is-method provided we prefer it over the getter. We might have to test if we don't overwrite the method then again with the getter, but I think that is not the issue here.
We are talking about the compiler and according to the bean spec it is perfectly legal to provide a getter instead of a is-method. Even having both is legal according to the spec. So I guess I am not really understanding the problem. Both compiler do have legal output, they are just not clear which way to go.
A reason we did implement only the getter and not the is-method is, because for a user it is more easy to remember the getter only, while he would have to remember the type of the property then too and a change in a file with a custom getter becomes less local.
But a bug in terms of violation of the beans specification this is not.
Bug
afaik the spec says that for a boolean property the getEnabled() as well as the isEnabled() methods are valid. But we can make this clear... on http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html is the bean spec. There you can read:
I am speaking from what I remember here, so it might need tests to be sure, but... what groovy does not is that if the parent class is providing an is-method, and you define a property of the same name, then Groovy will not overwrite the is-method, but generate an get-method.
From the runtime side we use the bean utils provided by the jdk, so if these utils follow the specification and a boolean is-method provided we prefer it over the getter. We might have to test if we don't overwrite the method then again with the getter, but I think that is not the issue here.
We are talking about the compiler and according to the bean spec it is perfectly legal to provide a getter instead of a is-method. Even having both is legal according to the spec. So I guess I am not really understanding the problem. Both compiler do have legal output, they are just not clear which way to go.
A reason we did implement only the getter and not the is-method is, because for a user it is more easy to remember the getter only, while he would have to remember the type of the property then too and a change in a file with a custom getter becomes less local.
But a bug in terms of violation of the beans specification this is not.