David,
Regarding the scope of JMM revision, in:
http://www.jcp.org/en/jsr/detail?id=133
section 2.5, we see:
...
Proposed areas of specification revision or clarification:
...
Immutable objects (objects whose fields are only set in their
constructor)
In regard to serialization of value types with RMI, the notion of
immutability is of some interest, in particular because the JDK
provides no standard way for custom-coded serialization classes
to set final fields (java.lang.reflect.Field.set() throws an
exception if called to set a final field), and the JDK provides
no standard way to create an object without calling its constructor.
Some kind of 'immutable' or 'freezeFinalFields' API that could
be used to notify an object that all of its final instance fields are now
frozen would be of great value for portable implementation of custom
serialization classes (when combined with a portable mechanism for
instantiating a class without calling its constructor). This could
work as follows:
(1) If an object is created using a constructor, its final instance
fields could be frozen implicitly by the constructor ending,
allowing no subsequent writes to any of them.
(2) If an object is created without calling any constructor, its
final fields could remain unfrozen until they are explicitly
frozen, thereby allowing setting via java.lang.reflect.Field.set.
I was hoping that the JMM would not require further revision just
to support portable coding of custom serialization classes, which
generally requires JNI programming, or horrible hacks like calling
private methods in java.io.ObjectInputStream using the reflection
API. Defining the semantics of setting final fields after the
constructor has exited does not on its own resolve the issue that
there is no portable API for this to be achieved.
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of David Holmes
> Sent: Monday, 20 October 2003 1:05 p.m.
> To: jmm
> Subject: Re: JavaMemoryModel: Motivation and Semantics for Immutable
> objects
>
>
> Language support for immutable objects is outside the scope of JSR-133
> and the JMM. If such a language feature were to exist the JMM would
> define it's behaviour of course.
>
> While there might be merit in the idea, the problem in my opinion is
> that immutability is often in the eye of the beholder. Consider C++
> const and the need for the mutable modifier to un-const something.
> Just because an object is logically immutable from an external
> perspective, it may not be physically immutable from an internal
> perspective. While transitive immutability might be desirable in some
> contexts it may not be desirable in all contexts. Further, in your
> scheme, how do you ensure that the same object is not manipulated via
> both mutable and immutable references? You seem want to make an object
> temporarily unmodifiable, or unmodifiable within a particular calling
> context, and that to me is quite distinct from an object actually
> being immutable. The advantage of immutability in a multi-threaded
> context comes from knowing that something can never change.
>
> If you can't trust the receiver of an object not to modify it then you
> should provide either an unmodifiable object (a read-only view or have
> modifying methods security checked in some way), or else provide an
> object which you don't care is modified. That's not to suggest that
> existing API's (like the event framework) can necessarily be
> retrospectively adapted in this way.
>
> Just my 2c.
>
> David Holmes
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT