RFR [JDK8]: 7153951: -Xlint:auxiliaryclass

Jonathan Gibbons jonathan.gibbons at oracle.com
Tue Oct 23 11:29:15 PDT 2012


On 10/23/2012 05:22 AM, Fredrik Öhrström wrote:
> 22 okt 2012 kl. 21:24 skrev Jonathan Gibbons:
>
>> The code in ClassReader looks like it is in the wrong place.  I would recommend putting the code into fillIn(ClassSymbol) and not in the attribute reader for the SourceFile attribute. There is no requirement that a SourceFile attribute must be present.  JVMS 7, 4.7.10 specifies that the SourceFile attribute is optional.
> Correct me if I am wrong, but it seems to me that only when the SourceFile attribute is present, is it possible to deduce that the loaded class is an auxiliary class.
> Therefore it seems to me that it is not a bad idea to check if the auxiliary bit should be set there.
>
>> The test test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java.html looks like a no-op, since @test is not the first token in the comment.
> It seems to me that jtreg is smarter than that. The test is run, despite me adding comments to the comment.

Maybe so, but you are relying on unspecified behavior.  The tag spec says:

The first token in the leading comment in the defining file of a test must be
"@test".  The harness discovers defining files by looking for such tokens.  A
file without comments is not a defining file.  A file whose leading comment
does not start with "@test" is not a defining file.


See http://openjdk.java.net/jtreg/tag-spec.txt

>
>> Also, the test looks weak, because you are not checking that the expected errors are generated.
> The test tests that no errors are generated. It is allowed to reference a top level type, not matching the source file name, as long as you do so
> from the same source file. It also tests, that the warning does not trigger on normal inner classes.
>
>> Even worse, you have omitted the /fail, so the test is written to expect the compilations to succeed, even though you are testing for errors.
> The test is written to expect the compilations to succeed, because the compilation should succeed.
>
> //Fredrik

OK, but you still have no tests that verify the correct messages are 
being generated.

-- Jon



More information about the compiler-dev mailing list