6

I can't see the reason why the Boolean wrapper classes were made Immutable.

Why the Boolean Wrapper was not implemented like MutableBoolean in Commons lang which actually can be reset.

Does anyone have any idea/understanding about this ? Thanks.

Avinash Singh
  • 3,421
  • 2
  • 20
  • 21
  • 1
    Also note that they are `final` - you can't extend a Wrapper and override it's methods. I'd suggest reading Josh Bloch's 'Effective Java' for a good overview of immutability. – James Bassett Mar 04 '13 at 04:00

4 Answers4

13

Because 2 is 2. It won't be 3 tomorrow.

Immutable is always preferred as the default, especially in multithreaded situations, and it makes for easier to read and more maintainable code. Case in point: the Java Date API, which is riddled with design flaws. If Date were immutable the API would be very streamlined. I would know Date operations would create new dates and would never have to look for APIs that modify them.

Read Concurrency in Practice to understand the true importance of immutable types.

But also note that if for some reason you want mutable types, use AtomicInteger AtomicBoolean, etc. Why Atomic? Because by introducing mutability you introduced a need for threadsafety. Which you wouldn't have needed if your types stayed immutable, so in using mutable types you also must pay the price of thinking about threadsafety and using types from the concurrent package. Welcome to the wonderful world of concurrent programming.

Also, for Boolean - I challenge you to name a single operation that you might want to perform that cares whether Boolean is mutable. set to true? Use myBool = true. That is a re-assignment, not a mutation. Negate? myBool = !myBool. Same rule. Note that immutability is a feature, not a constraint, so if you can offer it, you should - and in these cases, of course you can.

Note this applies to other types as well. The most subtle thing with integers is count++, but that is just count = count + 1, unless you care about getting the value atomically... in which case use the mutable AtomicInteger.

djechlin
  • 59,258
  • 35
  • 162
  • 290
  • 1
    When I am programming , I am not defining a 2 , I am defining a variable which holds a value like 2 , and in this case it is a reference so I should be able to change it to a new value. – Avinash Singh Mar 04 '13 at 03:47
  • @AvinashSingh So do it! `Integer count = 2; /* ... */; count = 3;` is perfectly legal. And `2` and `3` never have to change and your use case is met. – djechlin Mar 04 '13 at 03:48
  • 2
    If I change Boolean b = Boolean.TRUE and then I pass the it to another method say hello(Boolean b1){b1 = Boolean.FALSE} then it doesn't change value of b . It makes it difficult to pass the Boolean value between the pages , say from a JSF page to an Action which resets a button display – Avinash Singh Mar 04 '13 at 03:55
  • 1
    @AvinashSingh that is a legitimate tradeoff and in programming in Java you have to get used to it and structure your programs to avoid this use case, although in my opinion it's consistent with good OO design. Object `Foo` shouldn't be passing its `bool` to be modified; it should expose a method to modify it. Using `AtomicBoolean` can be a workaround but it's potentially an anti-pattern you'd rather design around needing than code around. – djechlin Mar 04 '13 at 03:57
  • I have used MutableBoolean from commons lang before . I guess my question is why Boolean class was not created like AtomicBoolean. I guess it has to do with memory ?? Thanks for your help. – Avinash Singh Mar 04 '13 at 04:00
  • 2
    @AvinashSingh No, it has to do with 1) good OO design and 2) concurrency, as explained in my answer. Or rather, those are the modern reasons for it, I don't know the history. – djechlin Mar 04 '13 at 04:07
  • Here's another example. Suppose you could change the value of a `Boolean`. Now you can't just return `Boolean.TRUE` from a method -- you have to return `new Boolean(true)`. Now you have to waste lots and lots of memory creating a new `Boolean` every time you want to wrap a primitive `boolean` in an object. If you just returned `Boolean.TRUE`, someone could do `TRUE.setValue(false)` and suddenly true is false and right is wrong and if you're _lucky_ your program will fail with a useful error message instead of firing off nuclear missiles. – Louis Wasserman Mar 04 '13 at 18:10
  • @LouisWasserman IIRC since Java 7 `Right` and `Wrong` are no longer implemented using `Boolean` so you should be fine in this case. – djechlin Mar 04 '13 at 18:24
3

Wrapper classes in Java are immutable so the runtime can have only two Boolean objects - one for true, one for false - and every variable is a reference to one of those two. And since they can never be changed, you know they'll never be pulled out from under you. Not only does this save memory, it makes your code easier to reason about - since the wrapper classes you're passing around you know will never have their value change, they won't suddenly jump to a new value because they're accidentally a reference to the same value elsewhere.

Similarly, Integer has a cache of all signed byte values - -128 to 127 - so the runtime doesn't have to have extra instances of those common Integer values.

Patashu
  • 21,443
  • 3
  • 45
  • 53
  • I understand the reason that it should have only either TRUE or false value but why does the reference gets reinitialized when I change Boolean b = Boolean.TRUE; – Avinash Singh Mar 04 '13 at 03:50
  • @Avinash Singh The semantics of the = operator on a reference type (any non-primitive) in Java is to change the reference held by the variable to the reference of the newly assigned object. – Patashu Mar 04 '13 at 03:51
  • Yes I understand that but why it doesn't allow changing the value the Boolean object holds , why it doesn't allow something like 'new Boolean().setValue(false)'; – Avinash Singh Mar 04 '13 at 03:58
  • This is almost correct. Unfortunately, `Boolean`, and `Integer`, have public constructors. So I can write `new Boolean(true)` and allocate a new instance on the heap. Likewise `new Integer(1)`. Tip: don't use `new` on these classes and let the compiler optimize away the extraneous memory use. Also, don't test for identity when you really want equality! – dsh Mar 04 '13 at 03:59
1

Patashu is the closest. Many of the goofy design choices in Java were because of the limitations of how they implemented a VM. I think originally they tried to make a VM for C or C++ but it was too hard (impossible?) so made this other, similar language. Write one, run everywhere! Any computer sciency justification like those other dudes spout is just after-the-fact folderal. As you now know, Java and C# are evolving to be as powerful as C. Sure, they were cleaner. Ought to be for languages designed decade(s) later! Simple trick is to make a "holder" class. Or use a closure nowadays! Maybe Java is evolving into JavaScript. LOL.

TimJowers2
  • 208
  • 2
  • 10
  • BTW, the reason I think "originally they tried to make a VM for C or C++" is because of a PPT I recall from Sun IIRC from the mid-1990's which all but stated that. – TimJowers2 Mar 10 '15 at 17:46
0

Boolean or any other wrapper class is immutable in java. Since wrapper classes are used as variables for storing simple data, those should be safe and data integrity must be maintained to avoid inconsistent or unwanted results. Also, immutability saves lots of memory by avoiding duplicate objects. More can be found in article Why Strings & Wrapper classes are designed immutable in java?

Patchikori Rajeswari
  • 69
  • 3