45

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Oleg Vazhnev
  • 23,239
  • 54
  • 171
  • 305
  • 6
    Boolean values are normally tested using `isXXX` methods instead of `getXXX` – pjp Sep 06 '09 at 12:15
  • 2
    @pjp `isXXX` is only for those primitive `boolean`s. We should stick to `getXXX` for those `Boolean`s. – Jin Kwon Dec 04 '14 at 11:50

9 Answers9

66

Immutable classes are easier to work with. They'll never change and there will be no problems with concurrent code. (Basically, there are fewer possibilities 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 multiple threads or plain old org.apache.commons.lang.mutable.MutableBoolean.

Thomas Jung
  • 32,428
  • 9
  • 84
  • 114
  • 2
    I did write "mutable" in my java.lang.String comment object and could not change it again. :-) – Thomas Jung Sep 06 '09 at 11:58
  • 1
    this one is intersting. probably i should realy use AtomicBoolean... thanks – Oleg Vazhnev Sep 06 '09 at 13:47
  • 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? – Oleg Vazhnev Sep 06 '09 at 18:12
  • 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 Sep 07 '09 at 18:58
  • `MutableBoolean` - very useful. Can be made `final` for use in lambdas when you don't need to overhead of locking associated with `AtomicBoolean`. Thank you! – jocull Sep 16 '20 at 14:51
29

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
  • 51,711
  • 9
  • 123
  • 115
24

If you are using Java 5 or higher then use AtomicBoolean

  • 8
    @monzonj: The `java.util.concurrent` classes do not use `synchronized`, they use the much better optmized locking constructs. `AtomicBoolean` will have a totally insignificant performance overhead when used as a contained for a `boolean`. if you can demonstrate otherwise, please show us. – skaffman Jan 12 '11 at 14:42
  • 5
    @monzonj: It doesn't have a significant performance overhead at all in any case. Also there is a lot to be gained from using the right tool for the right job. Regardless of what you think of some micro-performance hit that you can't measure, this highly optimized class was created for a reason, I doubt you can do better. –  Jan 12 '11 at 23:46
  • 2
    @monzonj - your assertion that *"atomic assignments can only be done through synchronization"* is mis-informed at best, there is the concept of *lock free synchronization* and if you actually look at the source for `AtomicBoolean` you will see that there is no usage of the `synchronized` keyword anywhere! You are spreading misinformation with your uninformed comment at best. –  Mar 18 '15 at 18:27
8

You can use a boolean array

final boolean[] values = { false };
values[0] = true;
user2218625
  • 91
  • 1
  • 2
5

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
  • 268,207
  • 37
  • 334
  • 440
  • 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 – Oleg Vazhnev Sep 06 '09 at 17:41
  • 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 Sep 06 '09 at 17:45
  • 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 :) – Oleg Vazhnev Sep 06 '09 at 17:54
  • So long as you're aware of the issues. Sounds like you are :-) – Brian Agnew Sep 06 '09 at 17:57
5

What about just using the boolean primitive?

private boolean value;

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

public boolean getValue() {
    return value;
}
Tom Jefferys
  • 13,090
  • 2
  • 35
  • 36
  • 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) – Oleg Vazhnev Sep 06 '09 at 13:40
  • 3
    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 Sep 06 '09 at 15:08
  • @soru +1 That's a great way to think about the problem. – dhable Sep 06 '09 at 17:25
3

The answer I liked most was from Adam to write your own wrapper class... OK

/* Boolean to be passed as reference parameter */
public class Bool {

     private boolean value;

     public Bool() {
         this.value = false;
     }

     public boolean is() {
         return this.value;
     }

     public void setTrue() {
         this.value = true;
     }

     public void setFalse() {
         this.value = false;
     }
 }
Lukas
  • 391
  • 4
  • 11
0

If you are using Android, you can use the android.util.Mutable* objects which wrap various primitive values. For example, quoting from the SDK source:

public final class MutableBoolean {
  public boolean value;

  public MutableBoolean(boolean value) {
      this.value = value;
  }
}
vonWippersnap
  • 483
  • 3
  • 9
-1

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
  • 8,968
  • 3
  • 34
  • 47
  • 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 – Oleg Vazhnev Sep 06 '09 at 17:44