> > Changing the code to actually show the internal reference shows that
> > the deserialized version produces the same results as the one before
> > serialization.
>
> What exactly do you mean by "same results"? Of course string values
I apologize for being unclear, by same results, I meant that:
System.out.println(a1 == a2);
for (int i = 0; i < a1.length; ++i)
{
System.out.println(i + ": " + (a1[i] == a2[i]));
}
produced the same output as:
System.out.println(c1 == c2);
for (int i = 0; i < c1.length; ++i)
{
System.out.println(i + ": " + (c1[i] == c2[i]));
}
meaning that there is no difference between the original values and the
deserialized ones.
> remain the same. I was talking about internal representation (i.e. the
> char arrays used). You cannot see that with a Java program alone, you
The intern() method returns a reference to the internal reference used
by the string object (according to the javadoc anyway).
> need a memory profiler or a debugger to actually see those instances and
> determine which are identical and which not.
[quoted text clipped - 10 lines]
> not be an issue for short lived applications but it certainly can be for
> long running apps.
I agree the intern() method should probably never be used. I was using
it here to demonstrate that the objects were pointing to the same
reference internally.
> Regards
>
> robert
Please forgive but, I don't understand what the example is trying to
demonstrate when the tests performed on the deserialized objects
produce the same output as the tests on the original objects.
false
0: true
1: false
-----------------------------------
false
0: true
1: false
Robert Klemme - 19 Sep 2006 14:49 GMT
>>> Changing the code to actually show the internal reference shows that
>>> the deserialized version produces the same results as the one before
[quoted text clipped - 15 lines]
> System.out.println(i + ": " + (c1[i] == c2[i]));
> }
Ok, now I understand. But that was not the main point of that piece of
code.
> meaning that there is no difference between the original values and the
> deserialized ones.
With regard to internal relationships between instances, yes. But
deserialized instances are differently set up with regard of size and
sharing of the internal buffer.
>> remain the same. I was talking about internal representation (i.e. the
>> char arrays used). You cannot see that with a Java program alone, you
>
> The intern() method returns a reference to the internal reference used
> by the string object (according to the javadoc anyway).
I am not sure I fully agree, there is no such thing as an "internal
reference". "interned reference" is probably a bit better.
String.intern() will either return the same ref and store it in its
internal map (or whatever representation Sun chose) or you get a
reference to another instance representing an equivalent string but
already present in the internal data structure.
Quote:
A pool of strings, initially empty, is maintained privately by the class
String.
When the intern method is invoked, if the pool already contains a string
equal to this String object as determined by the equals(Object) method,
then the string from the pool is returned. Otherwise, this String object
is added to the pool and a reference to this String object is returned.
>> Using intern() might also be a bad idea for changing data because
>> interned strings will continuously increase the VM's memory. This might
[quoted text clipped - 4 lines]
> it here to demonstrate that the objects were pointing to the same
> reference internally.
Not exactly: you interned the strings after deserialization and thus it
comes at no surprise that they point to the same instance after you did
that.
> Please forgive but, I don't understand what the example is trying to
> demonstrate when the tests performed on the deserialized objects
> produce the same output as the tests on the original objects.
As said, that output was not the main point. As I wrote above, set a
breakpoint at the line indicated and then look at object identities.
Then you'll see what I mean and try to convey from the beginning.
Kind regards
robert