JLS updates

[Dan Heidinga]

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 <daniel.smith at oracle.com> wrote:

> On Aug 31, 2022, at 11:54 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>
> On Aug 30, 2022, at 12:42 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>
> On Aug 30, 2022, at 12:18 PM, Dan Smith <daniel.smith at oracle.com> 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'.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220907/04de5a20/attachment.htm>