RE: FW: Java Vs RPG on iSeries

["David Morris" <David.Morris@xxxxxxxxxxxxx>]

I am trying to understand your alarming declaration and trying to see
how it would be a problem with a String. I can see how out of order
execution could create a duplicate object in a case where you are
doing something like this:

if (null==myString) String myString = new String("string");

and it would seem that any lock that doesn't key on a single item (not

tied to a thread) will potential fail. But I think it would be a pretty

unusual case for this to be a problem with a String or other immutable

object like a Double as long as you use the class comparitor and
comparable interfaces. Is this the case or am I missing the point?

David Morris

>>> kulack@us.ibm.com 09/19/02 10:58AM >>>

On 09/19/2002 at 01:28:33 AM, java400-l-admin@midrange.com wrote:
What happens if you _define_ an object such that its contents _never
change_ after the "new" (constructor) finishes?  Answer:  It is
automatically thread safe and everyone and his brother can have
references
to it without any synchronization.  That's an immutable object.  Very
relevantly, "String" is an immutable object and so is always thread
safe.
--- end of excerpt ---

Careful... Which JVM release? Pre or Post JSR 133?
Multithreading is a bit too complex even for this statement. Its
almost
always
more complex than someone thinks it is. JSR 133 tries to address it in
some
pieces, but
I don't know details about when that JSR was/is going to be complete
implemented, but
this is NOT true in general.  Do you know?

For others on the list...
On most hardware the statement about immutable objects is true.
However, on hardware that is weakly  consistent (i.e. allows unordered
storage access), this is
not true.

To really be safe, you simply CANNOT access objects/storage in one
thread
that were
created/initialized/modified in any other thread WITHOUT
synchronization.
PERIOD.
There are many tricks and exceptions that DON'T WORK. In a
multi-threaded
application,
anything that can theoretically fail, WILL, and you can't rely on it.

Here's one reference, see this.
http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1073.pdf

In the "Idioms and Pitfalls" sections, see "Safe Immutable Objects".
You'll need to be a member of JDC (Java Developer Connection) but see
this:
The one I liked most was a similar presentation in the 2000 JavaOne.