Comments based on my latest read through: 8.1.1.5 identity and value Classes > The class is neither abstract not the class Object Typo? I think that should be "nor" rather than "not"
I don't recall seeing these restrictions - non-static fields, synchronized methods, etc - in the JVMS update. Maybe I missed them? Otherwise, I think we need to add them to Ch.4 in the static constraints section as checks against value classes as well. 9.8 Functional Interfaces I'm not sure I follow the restriction on functional interfaces not being "sealed, identity, or value". Sealed makes sense as it is about limiting who can implement the interface. Is this an implementation concern? 15.8.3 this > Use of this in a constructor of a value class is restricted. It is a compile-time error if a this expression occurs in the constructor of a value class unless one of the following is true: > The this expression appears at a point where all blank final instance fields of the class have been definitely assigned (16) I'm unclear on the rationale for this restriction. If I wanted to expose a value constructor that returned the default (all-zeros) instance, it would need to explicitly zero each field? Seems like we're trying to solve the sins of the past here (like we often do when making things null-hostile) when it doesn't apply in the same way. We're not leaking an uninitialized value - we always start from a completely (zero) initialized value. --Dan On Wed, Aug 31, 2022 at 6:15 PM Dan Smith <[email protected]> wrote: > On Aug 31, 2022, at 11:54 AM, Dan Smith <[email protected]> wrote: > > On Aug 30, 2022, at 12:42 PM, Dan Smith <[email protected]> wrote: > > On Aug 30, 2022, at 12:18 PM, Dan Smith <[email protected]> wrote: > > FYI, I've made some minor fixes to the JLS change document supporting > Value Objects, published here: > > > http://cr.openjdk.java.net/~dlsmith/jep8277163/latest > > > One change I'll need to make: an interface is not a functional interface > if it is `identity` or `value`; but this should also be the case if any > *superinterface* is `identity` or `value`. (Ultimately, the implementation > should be free to generate identity objects or value objects to encode > lambdas and method references.) > > > And another (just want to memorialize these so I can fix them later): rule > in 8.1.1 about 'final' conflicting with 'sealed' also applies to the > implicit 'final' of a concrete value class. (More generally, anywhere > 'final' is mentioned as a class modifier, need to be sure it's clear that > this includes the implicit 'final'.) >
