Changing the value of Boolean?


B

Blueyonder

Sure I've read somewhere (but can't find it now) that you cannot change the
value of a Boolean tyep variable. You have to set it each time like this -

////////////////////////////////////////////////////////////
Boolean b = new Boolean(true);

b = new Boolean(false);
////////////////////////////////////////////////////////////

Is this correct?

thanks

harry
 
Ad

Advertisements

C

Christophe Vanfleteren

Blueyonder said:
Sure I've read somewhere (but can't find it now) that you cannot change
the value of a Boolean tyep variable. You have to set it each time like
this -

////////////////////////////////////////////////////////////
Boolean b = new Boolean(true);

b = new Boolean(false);
////////////////////////////////////////////////////////////

Is this correct?

thanks

harry

Yes, once a Boolean is created, it's value can not be changed (as is the
case with all "wrapper" types, such as Integer, Long, ...). We call such
classes immutable.

But in the case of boolean, instead of creating a new Boolean using
something like "new Boolean(false)", use the Boolean b = Boolean.FALSE
instead.

It prevents having to create an extra Boolean object, which would behave
exactly the same as new Boolean(false) anyway.
 
A

Alex Hunsley

Blueyonder said:
Sure I've read somewhere (but can't find it now) that you cannot change the
value of a Boolean tyep variable. You have to set it each time like this -

////////////////////////////////////////////////////////////
Boolean b = new Boolean(true);

b = new Boolean(false);
////////////////////////////////////////////////////////////

Is this correct?

thanks

harry

Yup. If you look at the API doc for boolean, you can see that it is
immutable (i.e. can't be changed once you've made it).

Please post simpler questions like this to comp.lang.java.help btw, as
it's more suited...

alex
 
X

xarax

Christophe Vanfleteren said:
Yes, once a Boolean is created, it's value can not be changed (as is the
case with all "wrapper" types, such as Integer, Long, ...). We call such
classes immutable.

But in the case of boolean, instead of creating a new Boolean using
something like "new Boolean(false)", use the Boolean b = Boolean.FALSE
instead.

It prevents having to create an extra Boolean object, which would behave
exactly the same as new Boolean(false) anyway.

Exactly right. A simple idiom is:

{
boolean bool = methodThatReturnsPrimitiveBoolean();
Boolean theBoolean;

/* Translate boolean primitive to Boolean instance. */
theBoolean = (bool ? Boolean.TRUE : Boolean.FALSE);
}
 
S

Steve W. Jackson

xarax said:
::> Blueyonder wrote:
:>
:> > Sure I've read somewhere (but can't find it now) that you cannot change
:> > the value of a Boolean tyep variable. You have to set it each time like
:> > this -
:> >
:> > ////////////////////////////////////////////////////////////
:> > Boolean b = new Boolean(true);
:> >
:> > b = new Boolean(false);
:> > ////////////////////////////////////////////////////////////
:> >
:> > Is this correct?
:> >
:> > thanks
:> >
:> > harry
:>
:> Yes, once a Boolean is created, it's value can not be changed (as is the
:> case with all "wrapper" types, such as Integer, Long, ...). We call such
:> classes immutable.
:>
:> But in the case of boolean, instead of creating a new Boolean using
:> something like "new Boolean(false)", use the Boolean b = Boolean.FALSE
:> instead.
:>
:> It prevents having to create an extra Boolean object, which would behave
:> exactly the same as new Boolean(false) anyway.
:>
:> --
:> Kind regards,
:> Christophe Vanfleteren
:
:Exactly right. A simple idiom is:
:
:{
: boolean bool = methodThatReturnsPrimitiveBoolean();
: Boolean theBoolean;
:
: /* Translate boolean primitive to Boolean instance. */
: theBoolean = (bool ? Boolean.TRUE : Boolean.FALSE);
:}

I agree with the recommendation to use the static member variables of
Boolean as described. But Sun's source code for the static variables
TRUE and FALSE in the Boolean class are both defined using the "new
Boolean" operation. So it's still necessary to create a new object on
the JVM's heap.

= Steve =
 
T

Thomas Schodt

Steve said:
I agree with the recommendation to use the static member variables of
Boolean as described. But Sun's source code for the static variables
TRUE and FALSE in the Boolean class are both defined using the "new
Boolean" operation. So it's still necessary to create a new object on
the JVM's heap.

But just once.

As it is static initialization, Boolean.TRUE and Boolean.FALSE will
reference two objects that get created when the Boolean class is loaded.

From then on the same two objects are just re-used.
You will even be able to compare them with ==
 
Ad

Advertisements

D

Dale King

Exactly right. A simple idiom is:

/* Translate boolean primitive to Boolean instance. */
theBoolean = (bool ? Boolean.TRUE : Boolean.FALSE);

And starting with JDK1.4 you no longer have to do that. There is now a
Boolean.valueOf( boolean ) method that does exactly the same thing.
 
Ad

Advertisements

S

Steve W. Jackson

Thomas Schodt said:
:Steve W. Jackson wrote:
:
:> I agree with the recommendation to use the static member variables of
:> Boolean as described. But Sun's source code for the static variables
:> TRUE and FALSE in the Boolean class are both defined using the "new
:> Boolean" operation. So it's still necessary to create a new object on
:> the JVM's heap.
:
:But just once.
:
:As it is static initialization, Boolean.TRUE and Boolean.FALSE will
:reference two objects that get created when the Boolean class is loaded.
:
: From then on the same two objects are just re-used.
:You will even be able to compare them with ==

Good point. Thanks.

= Steve =
 

Top