Dan, Many thanks for the careful updates and working so closely with all of us with each iteration.
Couple of minor comments: 1. Since we postponed this, and each release will change the ClassFile Version: - the new attributes will be in ClassFile Version 55 - If we want to use the new versioning, that would be 18.9 (rather than 11) 2. 3.7 Code example update - there is an invokespecial #4 // Method Near.getItNear()I I don’t think getItNear exists in the green example. I assume you meant Near.getIt(). 3. 5.4.2. Preparation: 2nd changed paragraph - The loader constraint equation below compares types relative to L2 (which is the class loader for the selected method) vs. L3. I do not see L3 defined here. I believe that <I, L3> is intended to be the super interface which declares the method in the first part of the sentence. 4. 5.4.4 I like the improvements suggested in this email thread clarifying that a host_class_index refers to a Constant_Class. And thank you for the future reminder of the circularity issue if we allow classes to be private. 5.5.4.5 Thank you for the example and for sweating the details. As an implementor, I very much like having all of this information in one place in the JVMS. 6. 5.4.5 “the selected method of the invocation for an instance of a class or interface C” For invokeinterface and invoke virtual “C” is always an object ref which must always be a class not an interface. Assuming you might be looking ahead to having this also work for invoke special when we get rid of ACC_SUPER? Otherwise I think this might work better with “class C”. thanks, Karen > On Dec 1, 2017, at 7:52 PM, John Rose <john.r.r...@oracle.com> wrote: > > On Dec 1, 2017, at 4:41 PM, Dan Smith <daniel.sm...@oracle.com > <mailto:daniel.sm...@oracle.com>> wrote: >> >> I've uploaded what I believe could be a final spec for nestmates, here: >> http://cr.openjdk.java.net/~dlsmith/nestmates.html >> <http://cr.openjdk.java.net/~dlsmith/nestmates.html> >> >> Since October, changes include: >> >> - Tweaks to the explanatory material in 2.11.8 and 3.7 >> >> - Some restructuring of the new 5.4.4 text to be a little less disruptive >> and more clearly define "same nest" and "nest host". There are some subtle >> behavioral differences compared to the previous iteration when errors occur. >> >> - Added an example to 5.4.5 to illustrate transitive overriding >> >> —Dan > > I suggest changing the references to 18.3 to 10, based on today's information > copied below. > > — John > > > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000301.html > <http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000301.html> > > Begin forwarded message: >> >> From: mark.reinh...@oracle.com <mailto:mark.reinh...@oracle.com> >> Subject: Re: Draft JEP: Time-Based Release Versioning >> Date: December 1, 2017 at 7:59:47 AM PST >> To: volker.simo...@gmail.com <mailto:volker.simo...@gmail.com> >> Cc: jdk-...@openjdk.java.net <mailto:jdk-...@openjdk.java.net> >> >> 2017/12/1 3:11:18 -0800, volker.simo...@gmail.com >> <mailto:volker.simo...@gmail.com>: >>> thanks for publishing the draft. Overall it looks good! >>> >>> I have just a few comment :) >>> >>> 1. Is thisJEP (i.e. the new version scheme) intended to be targeted >>> for Java 10? >> >> It's intended to be targeted when it's ready, just like any other JEP. >> It's obviously desirable to have it in 10, but if it doesn't make it >> then it'll be in 11. >> >>> I would appreciate to have it in ten but aren't we already quite late? >>> This is specification relevant (i.e. has to go into JSR 383) because >>> it changes java.lang.Runtime.Version and various standard system >>> properties which refer to it. JSR 383 has to be renamed from "Java SE >>> 18.3 Platform JSR" to "Java SE 10 Platform JSR" afterwards, right? >> >> That should be done anyway, regardless of whether this JEP makes it into >> JDK 10. If we change nothing in JDK 10, as it stands today, then the >> JDK 10 GA release will identify itself as 10, not 18.3. >> >>
