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
 
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 ==
 
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.
 
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 =
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,682
Members
48,796
Latest member
Greg L.

Latest Threads

Top