5

There is an option in Eclipse (Preferences -> Java->Code Style)

It allows "is" Prefix for getters if the return is boolean.

My question why does it not do the prefixing if the return is the wrapper class (Boolean) ?

user2817836
  • 205
  • 2
  • 6
  • 4
    Maybe because Boolean is an object? ... and this `is` setter feature is supposed to work with `boolean` only? Maybe this should be addressed to Eclipse community – gunar Sep 26 '13 at 08:53
  • 1
    I would say that it probably does not extract the type from a wrapper class. It just adds it as a return type. – Aashray Sep 26 '13 at 08:53
  • 2
    I don't believe it's on-topic to ask SO to justify how Eclipse features work - odds are this will lead to wild mass guessing. – millimoose Sep 26 '13 at 09:10
  • possible duplicate of [Valid Java bean names for booleans](http://stackoverflow.com/questions/799280/valid-java-bean-names-for-booleans) – flup Sep 26 '13 at 09:18

4 Answers4

9

This is simply because per the java beans specification/convention/implementation is prefix is only intended for primitive objects.

You can take a look at the PropertyDescriptor class source (getRealMethod):

 if (readMethodName == null) {
    Class type = getPropertyType0();
    if (type == boolean.class || type == null) {
        readMethodName = "is" + getBaseName();
    } else {
        readMethodName = "get" + getBaseName();
    }
    }

So eclipse is only conforming to this.

Edit: now why the property descriptor is made this way is another question, probably Java folks decided that the possibility of null return type and the "is" prefix may be misleading.

Kemoda
  • 284
  • 1
  • 9
  • This is not the reason. answer should tell why – Ruchira Gayan Ranaweera Sep 26 '13 at 09:21
  • @Ruchira The question is why is eclipse not allowing it => the answer because it tries to be conform to the PropertyDescriptor behaviour since many projects are using it (eclipselink, hibernate validator, etc). And allowing to use "is" prefix with Boolean properties can lead to unexpected behaviour. – Kemoda Sep 26 '13 at 09:28
  • first of all this is not a behavior of `eclipse`. This is behavior of `Java` – Ruchira Gayan Ranaweera Sep 26 '13 at 09:32
2

boolean is a primitive type and Boolean is an object. An object has other properties aside from just being true or false. So perhaps this is the reason why they designed it for the primitive type only.

If there's a getter named isActive, you would want it to return either true or false, not null or anything else.

Sajal Dutta
  • 18,272
  • 11
  • 52
  • 74
0

In primitive type boolean, only true and false are possible. But if you use Object type Boolean, null is also accepted. Normally is not suitable in such a scenario. 

  public class MyClass{
   private boolean status;
   private Boolean sts;

   public boolean isStatus(){
      return status;
   }

   public Boolean getSts(){
      return sts;        
   }

   // setters
  }

When we call isStatus result definitely true or false. It is make sense. But isSts can return null. This is some what not logical. This may be the reason to use get for Object type.

Ruchira Gayan Ranaweera
  • 34,993
  • 17
  • 75
  • 115
  • I dont see how the possibility of null is relevant for the getter prefix – Kemoda Sep 26 '13 at 09:12
  • It is. `object.isSomething()` should return a boolean, period. It's IMO a bad design and very unusual to return an other value. – johan d Sep 26 '13 at 09:29
0

When the isFoo/setFoo special case of the getter and setter naming convention for properties was established, Boolean was considered more closely related to all other object types than to the boolean primitive type; the result of getFoo can be null, the result of isFoo cannot.

Now that the Java language has automatic boxing and unboxing of primitive types, there's a greater chance of Boolean variables interacting with boolean properties, but Boolean properties remain unusual because setting them to null remains a strange and usually troublesome use case.

Lorenzo Gatti
  • 1,260
  • 1
  • 10
  • 15