Dan S, You are correct .The JVMS wording is accurate in terms of behavior, since the bullets represent the resolved method and you already have bullets for public and protected, so this bullet does only need to cover package private. So I withdraw the request for a change.
From an implementation standpoint, when we pre-cache the selection information hotspot at least does not track the resolved method information, so we always perform the transitive overriding check. I think Dan H and Graham’s request to add some examples would be valuable. Specifically they asked me a couple of questions that could use clarifying: 1) is it sufficient to check that you override the resolved method, or that you override the resolved method or direct superclass? - No - see the example below. 2) Does each package private method need its own vtable slot? Potentially yes. Since we pre-calculate the size it is much cleaner that way. I could imagine cases in which the only methods in the overriding chain so far were all package private in the same package - and I don’t have a counter-example of that in which you would have to have a separate entry. We are still going to use a separate entry since the complexity budget is already high. Here is an example that might be useful: P1.A: PP m() P1.B extends A, Pub m() P1.C extends B, PP m() P2.D extends C, PP m() P2.D.m should override P1.A.m P2.D.m should not override P1.C.m Correct me folks if this is inaccurate, thanks, Karen > On Nov 16, 2017, at 10:40 AM, Dan Smith <[email protected]> wrote: > >> On Nov 10, 2017, at 12:48 PM, Karen Kinnear <[email protected] >> <mailto:[email protected]>> wrote: >> >> Dan Smith - this is a request for a change to one line of the Nestmates JVMS >> 5.4.5 Overriding. >> The rest of the wording for 5.4.5 is an improvement, so thank you. >> >> Dan Heidinga, Graham Chapman (IBM) and I met to discuss the JVM >> implementations of >> JVMS 5.4.5 Overriding, specifically to discuss the expectations relative to >> the >> bullet describing transitive overriding that was added for CFV 51 in JDK7. >> >> The JVMS 9 bullet says: >> mC overrides a method m' (m' distinct from mC and mA) such that m' >> overrides mA. >> >> The proposed NestMates bullet says: >> mC overrides a method m' (m' distinct from mC and mA) such that m' overrides >> mA mA is marked neither ACC_PUBLIC nor ACC_PROTECTED nor ACC_PRIVATE, and, >> where mC is declared in a class C and mA is declared in a class A, there >> exists a method mB declared in a class B, such that C is a subclass of B, B >> is a subclass of A, mC can override mB, and mB can override mA. >> From examining a number of test cases, we would like to request that the >> updated version be modified to remove the restriction on mA as package >> private. We need to perform what I call transitive overriding checks as long >> as mA is not ACC_PRIVATE. > > The intent is not to change the meaning, but to clarify that the check only > needs to be performed when mA is package-access. Notice that this appears in > a list of or'ed conditions, and the first two are "mA is marked ACC_PUBLIC" > and "mA is marked ACC_PROTECTED". So in those cases, the enclosing "One of > the following is true" is already true. > > If, in fact, some sort of transitive analysis is needed, then the problem is > deeper than just the access flags checked in this bullet. > > Could you supply an example where the current rules define > unwanted/unimplemented behavior? > >> Dan H also suggested it would be very helpful to all of us if you could add >> some non-normative examples in the spec here. Examples that might be useful >> would be: > > Sure, some discussion about package access would be helpful. I can do so. > > —Dan
