0

We know that new JMM gives guarantees for not seeing partially constructed object or more than one value of its final fields. http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.2

My question is -

Is same final guarantees are applicable, when we deserialize an immutable object(all fields declared as final)?

http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.3

(UPDATE)

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6379948 (Bug for Deserialization)

Is same final guarantees are applicable, when we clone an immutable object(all fields declared as final)?

veritas
  • 2,444
  • 1
  • 21
  • 30
  • At least for cloning this is certainly *yes*. – Marko Topolnik Jul 06 '13 at 19:20
  • after a little thought i think cloning an immutable object will not solve any purpose. There would never be any scenario where i would need to clone an immutable object. am i right in my assumption? – veritas Jul 08 '13 at 17:32
  • 1
    There are some marginal scenarios where you actually want a distinct object. I had one: conditional atomic swap operation, where the only way to know for sure that the swap happened is to have a new, distinct object you are swapping in. – Marko Topolnik Jul 08 '13 at 19:19
  • @MarkoTopolnik Hi am sorry i didn't understand the scenario. Why would you swap a object with its clone. I think am missing something. – veritas Jul 08 '13 at 19:53
  • 1
    It's not something you'll encounter in Java; it's an example from Clojure, which has *atoms* and a `swap` operation defined on them. `swap` takes an arbitrary transforming function. From the outside you sometimes want to know that a condition within that function evaluated to `true`, and the way to signal this is by swapping in a distinct clone. – Marko Topolnik Jul 08 '13 at 20:03

2 Answers2

0

If you pass an object to another thread using a thread safe collection or container, you will see the correct state for the class. This means the built in queues, synchronized collections, locked collections, atomic reference or volatile.

To even see such a problem you would have to be using an access which itself must not be thread safe as any write/read barrier you use, even indirectly, would ensure correct initialisation.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • am talking about immutable objects here. For which i don't need thread safe collection (main advantage in context of immutable objects). if the object is getting created through constructor i have that guarantee (because of final semantics defined by new JMM). My questions is do have the same guarantee during deserialization and cloning and where such a documents is published – veritas Jul 07 '13 at 00:55
0

When deserializing an object, the only way you can get a reference to it is after deserialization has completed and it is returned. At that point, its fields have been assigned.

Generally, the only way to get a reference to an incompletely initialized object is if its superclass constructor passes a reference to this to another thread.

If the concern is that the values of mutable fields of the deserialized object not marked with volatile might be in the processor cache on one CPU and not flushed to main memory, I actually can't answer that with authority, but I would be very surprised if the guarantees were not the same as those of running a constructor.

Tim Boudreau
  • 1,741
  • 11
  • 13
  • actually the guarantees are not the same d because of the reordering and visibility effects. It may happen i could see two values of final fields while deserializing. see this http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6379948 – veritas Jul 12 '13 at 03:08