Newbie: cloning a Number

[Chris Smith]

class MyImmutableClass {
private final char[] array = {'T', 'w', 'i', 's', 't', 'e', 'd', '
', 's','u', 'c', 'k', 's'};
public char[] getArray() {
return (char[])array.clone();
}
}

This class is immutable.

Hmm.

(1)
public class MySub extends MyImmutableClass
{
private char[] realArray = "Twisted sucks".toCharArray();
public char[] getArray() { return realArray; }
}

(2)

MyImmutableClass mic = ...;
Field f = MyImmutableClass.class.getDeclaredField("array");
char[] array = (char[]) f.get(mic);
array[ 8] = 'r';
array[10] = 'l';
array[11] = 'e';

Of course, (1) only works if you don't control the object creation, so
that subclasses are possible. (2) only works if you're running under no
or a very permissive security manager. But it's hard to say that
MyImmutableClass is 100% immutable.

 

[Tor Iver Wilhelmsen]

class MyImmutableClass {
private final char[] array = {'T', 'w', 'i', 's', 't', 'e', 'd', '
', 's','u', 'c', 'k', 's'};
public char[] getArray() {
return (char[])array.clone();
}
}

This class is immutable.

No, because it's not final. The class or the getter method needs to be
final, or you will have subclasses altering behavior as another reply
shows.

 

[Daniel Pitts]

class MyImmutableClass {
private final char[] array = {'T', 'w', 'i', 's', 't', 'e', 'd', '
', 's','u', 'c', 'k', 's'};
public char[] getArray() {
return (char[])array.clone();
}
}

This class is immutable.

Hmm.

(1)
public class MySub extends MyImmutableClass
{
private char[] realArray = "Twisted sucks".toCharArray();
public char[] getArray() { return realArray; }
}

(2)

MyImmutableClass mic = ...;
Field f = MyImmutableClass.class.getDeclaredField("array");
char[] array = (char[]) f.get(mic);
array[ 8] = 'r';
array[10] = 'l';
array[11] = 'e';

Of course, (1) only works if you don't control the object creation, so
that subclasses are possible. (2) only works if you're running under no
or a very permissive security manager. But it's hard to say that
MyImmutableClass is 100% immutable.

Ah, point taken.

 

[Daniel Pitts]

Yes this is correct.
I just thought that this was the whole purpose of a "Number" class. ie
not needing to say if it's actually an integer or a double, but leaving
this to when real calculation is done.

Also my parameters are displayed in JFormattedTextFields which I would
like not to display Integers and Double the same way (with or witout
fraction digits). So keeping this info seemed important to me.

From my C++ background I would have implemented the standard math
operators (+ - * /) on Number such that the polymorphism is used (ie if
Number*Number is actually Integer*Integer: do integer math. If it's
Double*Integer do double math). But this does not seem to be the purpose
of the Number class in Java.
(what's it's purpose actually?)

Best regards
Phil

I believe the Number class's primary purpos is to provide a constant
way to represent numeric values as Objects in a type independant way.
All Number subclasses have intValue(), floatValue(), etc..., so that
you can convert from a Number object to any primative type.

Other than that, most people use a specific Number subclass, rather
than Number itself.

 

[Ingo Menger]

I'll repeat my earlier assertion: "``Immutable'' is a slightly
fuzzy concept." The harder you try to pin it down, the fuzzier it
becomes.

With all due respect: Its easy.
An object is immutable if it's class (a) contains only final fields and
(b) no references to mutable classes.

 

[Lew]

With all due respect: Its easy.
An object is immutable if it's class (a) contains only final fields and
(b) no references to mutable classes.

Also, if its (no apostrophe) class contains non-final fields or fields of a
mutable type, but guards against directly serving those references to its (no
apostrophe) clients.

Also, one has to declare the class final, or its accessor methods final.

Also, if the class is Serializable, the serialization/deserialization has to
guard against changes.

I may have forgotten something.

Maybe it's (with an apostrophe) not "fuzzy" so much as "difficult" or "tricky".

- Lew

 

[Patricia Shanahan]

I believe the Number class's primary purpos is to provide a constant
way to represent numeric values as Objects in a type independant way.
All Number subclasses have intValue(), floatValue(), etc..., so that
you can convert from a Number object to any primative type.

Other than that, most people use a specific Number subclass, rather
than Number itself.

Unfortunately, they are not required to have a consistent conversion to
BigDecimal. That is the only API type that can exactly represent the
value of any double, any long, any BigInteger, etc., and provides
operations on them.

Patricia

 

[Ingo Menger]

Also, if its (no apostrophe) class contains non-final fields or fields of a
mutable type, but guards against directly serving those references to its (no
apostrophe) clients.

Also, one has to declare the class final, or its accessor methods final.

This is not necessary for an *object* to be immutable as long as the
conditions stated above hold. To be sure, it makes not much sense to
speak of "immutable classes", only of immutable objects.

 

[Lew]

This is not necessary for an *object* to be immutable as long as the
conditions stated above hold. To be sure, it makes not much sense to
speak of "immutable classes", only of immutable objects.

Rrr?

Au contraire. I hear (read) the term "immutable class(es)" all the time. It
means a class that has been designed so that its attribute values are set
exactly once (canonically at construction time) for any given instance.

An instance of an "immutable class" is informally deemed an "immutable object".

I don't even understand what you mean that the conditions of immutability need
not hold for "an 'object' to be immutable". If a class is not immutable, then
every instance of it has the risk of its attribute values changing after
construction. It makes no sense, to me at least, to call an instance of a
non-immutable (i.e., mutable) class an "immutable object".

It seems that the definition of "immutable" is "fuzzy" after all.

- Lew

 

[Chris Uppal]

With all due respect: Its easy.
An object is immutable if it's class (a) contains only final fields and
(b) no references to mutable classes.

"if" perhaps, but "only if" ? I'd be willing (for the purposes of debate) to
posit that the conditions you mention are sufficient (I'd also be willing --
for the purposes of debate -- to attempt to demonstrate that the were not, in
fact, sufficient). What I am /not/ willing to posit (even for the debate) is
that those conditions are anything like necessary -- in fact I'd say they are
so restrictive as to be effectively useless.

For instance, String, Class, and BigInteger are all officially immutable, but
none of them satisfy both (a) and (b) (all of them, as a matter of fact, fail
both conditions).

-- chris

 

[Ingo Menger]

Rrr?

Au contraire. I hear (read) the term "immutable class(es)" all the time.

Sure. Just that "one hears it all the time" and "it makes sense and is
true" are different things.

It
means a class that has been designed so that its attribute values are set
exactly once (canonically at construction time) for any given instance.

An instance of an "immutable class" is informally deemed an "immutable object".

I don't even understand what you mean that the conditions of immutability need
not hold for "an 'object' to be immutable".

I didn't say that, I only said that a final class and certain
properties of the methods are not a precondition for immutability of
objects.

It seems that the definition of "immutable" is "fuzzy" after all.

It gets fuzzy as soon as you apply it to the concept "class".
Let me give a simple example.

class Immutable {
final public int intVal;
final public String strVal;
public Immutable(final int initi, final String inits) ...
}

Now, every object with *run time type* Immutable is immutable. Do you
agree?
And yet it's possible to write:

class Mutable<T> extends Immutable {
public T mutateMe;
...
}

According to your definitions, class Immutable is not immutable, since,
for example
Immutable foo = new Mutable<String>()
is an instance of Immutable, but is mutable.
Yet it still holds that a subset of Immutables instances are indeed
immutable, namely those with a *run time type* Immutable. So, in
deciding if something is immutable, one has to find out it's runtime
type and then look at the corresponding class definition to see if
changes are possible. This "something", however, can only be an object.
Thus, I prefer the notion of an immutable object. It is by no means
fuzzy.
Contrast this with the claim that "class Immutable is not immutable
(since it allows subclasses that could be used to create mutable
objects)". What does this claim tell us about the mutablity of objects
with run time type Immutable? Nothing.

 

[Ingo Menger]

"if" perhaps, but "only if" ? I'd be willing (for the purposes of debate) to
posit that the conditions you mention are sufficient (I'd also be willing --
for the purposes of debate -- to attempt to demonstrate that the were not, in
fact, sufficient). What I am /not/ willing to posit (even for the debate) is
that those conditions are anything like necessary -- in fact I'd say they are
so restrictive as to be effectively useless.

Ok. but please let me restate it more clearly, since I see now that
condition (b) does not express what I really meant (sorry, no native
english speaker):

An object is immutable if
(a) it's class has only final fields
(b) the object does not contain references to mutable objects
where with "fields" and "references" I mean those that are non static
and accessible to the outside world. (I am not considering Reflection
if and in so far as it allows to break the accessibility rules.)
If condition (a) were false, one could just set another value.
If condition (b) were false, one could pass a reference to a mutable
object to a method that indeed mutates that object and this would, in
turn, change the value of the object under consideration.
Thus, both (a) and (b) must be true.

For instance, String, Class, and BigInteger are all officially immutable, but
none of them satisfy both (a) and (b) (all of them, as a matter of fact, fail
both conditions).

Let's see. The only field that class String contains is
public static final Comparator<String> CASE_INSENSITIVE_ORDER
Condition (a) satisfied, but I admit that it would be better to state
explicitely, that static fileds do not matter anyway, because they do
not belong to an object.
Condition (b) satisfied also (ok, I admit that the original formulation
was misleading)
Likewise for BigInteger.

 

[Lew]

... Thus, I prefer the notion of an immutable object. It is by no means
fuzzy.
Contrast this with the claim that "class Immutable is not immutable
(since it allows subclasses that could be used to create mutable
objects)". What does this claim tell us about the mutablity of objects
with run time type Immutable? Nothing.

You make valid points. I think I see my disconnect.

I am looking from the POV of a class designer wishing to guarantee
immutability in a class design. I used the term "immutable class" to mean a
class that makes such a guarantee. I was going for the stronger sense of
compile-time immutability.

You are looking from the POV of a running app, in which case "class
immutability" is irrelevant and meaningless, but "object immutability" as a
run-time characteristic is both relevant and meaningful. In that context I
agree with your points wholeheartedly.

These are really two different kinds of "immutability" and should have
different terms. I could reserve "is immutable" for your definition, i.e.,
that a given instance cannot change meaningful value, and say "guarantees to
evince immutability for all instances" ("guarantees immutable", informally)
for a class designed so that it and any descendants will instantiate only
immutable objects.

Whether an object "is immutable" is not fuzzy, as you pointed out, and whether
a class "guarantees immutable" is a little fuzzy and a lot tricky to design.

I thank you for making this distinction evident to me.

- Lew