tags:

views:

773

answers:

9

I need a mutable boolean field in Java (I will return this field via get* method later and it should be possible to modify this field).

Boolean doesn't work because there are no set* methods in the Boolean class (I would say that Boolean is immutable, you can only change the reference, but you can't change the object itself).

I guess I can use Boolean array of size 1. But probably there are more elegant solutions?

Why doesn't Java have such a simple thing?

+3  A: 

Why not use the boolean primitive ?

e.g.

private boolean myFlag = false;

public void setMyFlag(boolean flag) {
   myFlag = flag;
}

Note your getter method can return a Boolean if required, due to the magic of autoboxing. This allows easy interchangeability between using primitives and their object equivalents (e.g. boolean vs. Boolean, or int vs. Integer).

So to address your edited responses re. the methods you have available,

public Object getAttribute(String attributeName)

can be implemented by returning an autoboxed boolean,.

Brian Agnew
i don't want to add special method to set something... everything should be implemented via Object returned from getAttribute. This is because i don't want to change very top-hierarchy class interface.all I need is a mutable boolean object... i do think that java.util.concurrent.atomic.AtomicBoolean probably the right choice
javapowered
Whilst I understand what you're doing, I'd say that I'm not sure this is a good design. I'd expect the containing object to look after manipulating fields, rather than handing them off to 3rd party code to change. i.e. it's the responsibility of the containing object to look after its fields and maintain consistent state etc. Just a heads up (you may be working under constraints that I'm not aware of, however)
Brian Agnew
i agree in most cases we should not use such practics.even "findbugs" reports "Array return type" as a "poor design" because object can be changed by third-parties.But this is how a lot of code already written and I just need to add few more things :)Moreover from the name of my field it will be clear that it supposed to be changed by third-parties, so I think it should not be a big problem :)
javapowered
So long as you're aware of the issues. Sounds like you are :-)
Brian Agnew
+1  A: 

Why don't you use the type boolean then? More info

Ammar
i only have this method: public Object getAttribute(String attributeName).I can't use boolean then. I guess one-element array is my choice :)
javapowered
I would go with a wrapper class instead.
Ammar
+4  A: 

What about just using the boolean primitive?

private boolean value;

public void setValue(boolean value) {
    this.value = value;
}

public boolean getValue() {
    return value;
}
Tom
this will work but you have to write two methods for each field.but i don't want to change existent interface. the only method I have is:public Object getAttrbiute(String attributeName)
javapowered
Adding the ability to set things _is_, in common sense terms, changing the interface. So it is best to have the actual written interface change to represent and track that change.
soru
@soru +1 That's a great way to think about the problem.
Dan
+7  A: 

Maybe write yourself a wrapper class

class BooleanHolder {
    public boolean value;
}

Or make a generic holder class (which means you will have to use class Boolean instead of primitive boolean):

class Holder<T> {
    public T value;
}

You then return the wrapper class instead of the value itself, which allows the value inside the wrapper to be modified.

Adam Batkin
this will work, but array of size 1 is a little simpler, imho :)
javapowered
You make an array of BooleanHolders if you need more than 1
nos
+5  A: 

Immutable classes are easier to work with. They'll never change and there will be no problems with concurrent code. (Basicly, there are fewer possiblities to break them.)

If you would like to return a reference to your Boolean value, you can use java.util.concurrent.atomic.AtomicBoolean if you're working with multible threads or plain old org.apache.commons.lang.mutable.MutableBoolean.

Thomas Jung
I did write "mutable" in my java.lang.String comment object and could not change it again. :-)
Thomas Jung
this one is intersting. probably i should realy use AtomicBoolean... thanks
javapowered
hm.. this is what I've read in javadoc: "An AtomicBoolean is used in applications such as atomically updated flags, and cannot be used as a replacement for a Boolean.". Why?
javapowered
It has an other API. Some features are missing like parsing and Comparable is not implemented. The performance characterics of AtomicBoolean will be different, too.
Thomas Jung
A: 

If I understand you correctly, you want to do something like this:

private boolean[] myBool = new boolean[1];
{ myBool[0] = false; }

  public Object getAttribute(String attributeName) {
    if (attributeName.equals("myBoolean")
      return myBool;
  }

and then elsewhere:

 boolean[] bool = (boolean[]) getAttribute("myBoolean");
 bool[0] = true;

This seems too tricky to me: I would be confused by this code. Booleans should be immutable and objects should not the updating the internal state of other objects directly.

If you absolutely must have this behavior, keep no local references: every time you need the value use the getAttribute method, then if the value has changed you will always be using the current value. Use some kind of a setter method to set the value, like Tom recommended.

Skip Head
yeap, this is tricky, that's because I've asked a question here :) Holder is also tricky (and a little more tricky, imho)... one-element array is a well-known workaround for such problem... but since we have java.util.concurrent.atomic.AtomicBoolean we don't need any workaround :)
javapowered
A: 

Apache Commons Lang has a MutableBoolean class.

skaffman
apache commons is like adding a dependency cancer to your project, Java 5 and above already has a built in AtomicBoolean.
fuzzy lollipop
"dependency cancer", right.... nothing like a good bit of hyperbole to make a point...
skaffman
A: 

Are you really saying that you want callers to be able to modify the object's boolean value by manipulating what gets returned? So that the object and caller would share a reference to it?

Just so I understand, given:

class OddClass {
   private Boolean strangeFlag;
   public Object getAttrbiute(String attributeName) { 
      if (attributeName.equals("strangeflag")) return (Object)strangeFlag; 
      ...
   }
}

And then caller does:

   Boolean manipulableFlag = (Boolean) myOddClass.getAttrbiute ("strangeflag");

And then later, if caller changes the value of manipulableFlag, you want that change to happen in the OddClass instance, just as though caller had instead used a setAttrbiute method.

Is that what you're asking?

In that case, you'd need a holder class, as suggested by Adam.

CPerkins
that's right, you understanding is correct. holder class is heavy workaround. at least i can use one-element array, but probably java.util.concurrent.atomic.AtomicBoolean is the best choice
javapowered
+1  A: 

If you are using Java 5 or higher then use AtomicBoolean

fuzzy lollipop