Community
Participate
Working Groups
Build 20030716 We fail a couple JCK tests with the 1.4a exclude list update (which seems to unleash previously excluded tests). Failures are: - stmt16503 - icls01791m12 - binc04901
stmt16503 is a check that compiler prevents access a local type using binary name (X$1$L) when compiling against binaries. Note that javac 1.4.2 doesn't notice the issue either, and jikes generates a warning when using a $-name.
When compiling against sources, we correctly reject this $-name usage scenario. Suspecting the exclude list is not accurate.
Actually. Our support for rejecting internal names is fooled by local BinaryTypeBinding answering false to #isNestedType().
stmt16503 is fixed.
icls01791m12 is checking that user can define this$0 field in member type (colliding with reserved enclosing instance name). Neither javac 1.4.2 or jikes 1.18 tolerate this either. No action planned.
javac 1.4.2 fails binc04901 as well. The test looks boggus. It assumes that if you remove the super interface a Verify error is thrown. In this case, the VM throws a IncompatibleClassChangeError. I will double check the VM specs in this case.
binc04901 is boggus. At runtime, the failure occurs when the invokeinterface bytecode is invoked with a Test object. Because this object doesn't implement the proper interface (Super in this case), the linking fails with an IncompatibleClassChangeError. This is specified in the JVM specs (page 282 of the second edition). There is no check to find out that an instance of Test cannot be stored as a Super. The JLS specifies that it should result in a VerifyError (see 13.5.2). So this is either a VM bug or JLS bug or a JVMS bug. I don't think we can do much on the compiler side. Ok to close as FIXED?
I am suspecting a problem with the exclusion list. stmt16503, icls01791m12 and binc04901 are still located in the latest jdk14.jtx, but not in jdk14a.jtx. If you look at stmt16503 and icls01791m12, they both refer to a bug id 4094180 that points to a bug closed as WONTFIX. Therefore it is impossible that this test can be removed from the excluded list.
I was also suspecting this exclude list to be a red herring (though it found a bug...). Before we close it, we should make sure the exclude list is bogus.
After further investigation, the exclude list matches jck1.4a, and we were incorrectly using jck1.4 with 1.4a exclude list. Closing as invalid (though we solved a bug with this).
