[pron]

1. Memory "bloat" is always a better use of resources than increased development time, regardless of how you have to pay for it.

2. How are Java's value types limited?

3. I find your calculation extremely pessimistic. Lambda expression are widespread a couple of years after their release, and I see no reason why value types will be different. I think that 5 years are a better estimate for wide use of value types.

[geodel]

Here is what I read from JEP 169

> Except for pointer equality checks, forbidden operations will throw some sort of exception. How to control pointer equality checks is an open question with several possible answers.

And more:

  Rules for permanently locked objects:
  
  - restrictions on classes of locked objects
      - all non-static fields must be final
      - there must be no finalizer method (no override to `Object.finalize`)
      - these restrictions apply to any superclasses as well
      - an array can be marked locked, but then (of course) its elements cannot be stored to
      - if not an array, the object's class must implement the marker type `PermanentlyLockable` (is this a good idea?)
  - restricted operations on locked objects (could be enforced, or else documented as producing undefined results)
      - do not use any astore or putfield instructions, nor their reflective equivalents, to change any field
      - do not lock (you may get a hang or a LockedObjectException)
      - do not test for pointer equality; use Object.equals instead (there may be a test for this)
      - do not ask for an identity hash code; use Object.hashCode instead (there may be a test for this)
      - do not call wait, notify, or notifyAll methods in Object
      - at the time it is marked locked, an object's monitor must not be locked (in fact, should never have been?)
  - side effects
      - elements of locked arrays are stably available to readers just like final object fields (i.e., there is a memory fence)
      - a locked object can be locked again, with no additional effect
      - any attempt to mutate a permanently locked object raises java.lang.LockedObjectException
      - any attempt to synchronize on a permanently locked object raises java.lang.LockedObjectException
  - object lifecycle
      - all objects are initially created in a normal (unlocked) state
      - an object marked locked cannot be "unlocked" (reverted to a normal state)
      - an object marked locked must be unreferenced by any other thread (can we enforce this?)
      - the reference returned from the (unsafe) marking primitive must be used for all future accesses
      - any previous references (including the one passed to the marking primitive) must be unused
      - in practice, this means you must mark an object locked immediately after constructing it
  - API
      - the method `lockPermanently` is used to lock an object permanently
      - there is a predicate `isLockedPermanently` which can test whether an object is locked or not
      - for initial experiments, these methods are in `sun.misc.Unsafe`; perhaps they belong on `Object` (cf. `clone`)`

With all this above I feel it is not exactly same as understood in languages which natively support value type.

[pron]

Java will natively support value types (and already does, just not user-defined value types). What you've quoted is the spec for locked arrays; those arrays are not value types, but reference types. I'm not sure about the relationship between the text in that JEP and the current work on value types: http://openjdk.java.net/projects/valhalla/