On Thu, 28 Jan 2021 07:24:12 GMT, Serguei Spitsyn <[email protected]> wrote:
>> The test failed because it expects that public/protected/default/private and >> static modifiers differ on the JVM level like in Java source code. However, >> only the ACC_PUBLIC modifier has an effect on interfaces. >> >> Here is my proposal from bug comments: >> >> I looked at the test and checked bytecode and spec. >> >> Indeed, the bytecode of all redefineclasses021bi redefined classes differs >> only by ACC_PUBLIC attribute. So there is no sense to test other access >> levels even they exist in JLS. >> >> The last redefinition adds 'static' modifier and verifies that there is no >> UOE is thrown. However static modifiers are also not set for interfaces >> because according to JLS it is set implicitly. >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.5.1 >> "A member interface is implicitly static (ยง9.1.1). It is permitted for the >> declaration of a member interface to redundantly specify the static >> modifier." >> The test already has been fixed to verify that UOE is not thrown but it just >> doesn't do anything, assuming that bytecode is the same. So I believe this >> test case might safely be deleted. >> >> >> It is also InnerClasses_attribute in redefineclasses021b which points to >> attributes of the inner class. However, the spec says that it used by the >> compiler only. Also, the test doesn't redefine this class but interface only. >> See https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-4.html: >> "inner_class_access_flags >> The value of the inner_class_access_flags item is a mask of flags used to >> denote access permissions to and properties of the class or interface C as >> declared in the source code from which this class file was compiled. It is >> used by a compiler to recover the original information when the source code >> is not available. The flags are specified in Table 4.7.6-A." >> >> So I think it is enough just to check public vs not public access modifiers. > > The updated TestDescription.java claims this: > * This test performs the following cases: > * 1. newclass01 - adding <public> interface-modifier > * 2. newclass02 - removing <public> interface-modifier > > Both interfaces 021bi and 021bir initially have public modifier in > newclass01/redefineclasses021b.java: > 35 public interface redefineclasses021bi { > 36 // ^^^^^^ > 37 void dummyMethod01(); > 39 } > 41 public interface redefineclasses021bir { > 42 void dummyMethod01(); > 44 } > and both are removed in the newclass02/redefineclasses021b.java: > 39 interface redefineclasses021bi { > 40 void dummyMethod01(); > 42 } > 44 /* public */ interface redefineclasses021bir { > 45 //^^^^^^^^ > 46 void dummyMethod01(); > 48 } > > It is not clear in what direction the classes are being redefined. > Could you explain a little bit? > > > redefineClasses/redefineclasses021.java: > * This test performs the following cases: > <br> > - * 1. newclass01 - adding <code>public</code> interface-modifier > <br> > - * 2. newclass02 - adding <code>protected</code> interface-modifier > <br> > - * 3. newclass03 - adding <code>private</code> interface-modifier > <br> > - * 4. newclass04 - adding <code>static</code> interface-modifier > <br> > + * 1. newclass01 - adding <code>public</code> interface-modifier > <br> > + * 1. newclass01 - removing <code>public</code> interface-modifier > <br> > > The change above does not match the TestDescription.java above. > Should it be like below?: > + * 1. newclass01 - adding <code>public</code> interface-modifier > <br> > + * 2. newclass02 - removing <code>public</code> interface-modifier > <br> Initially, the test has private redefineclasses021bi and public redefineclasses021bir in test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021b.java. The newclass01 changes redefineclasses021bi to be public and newclass02 changes redefineclasses021bir to private. ------------- PR: https://git.openjdk.java.net/jdk/pull/2093
