Regression in JDK8 build 78: javac complains about missing Class#isAnnotationPresent

Joe Darcy joe.darcy at
Thu Feb 28 16:32:31 PST 2013

Hello Uwe,

On 2/28/2013 1:31 PM, Uwe Schindler wrote:
> Hi Joe,
> I know about this warning and it generally appears on Java 7, but it was *not* printed out in that case (8b78)! The log I posted was the complete printout from javac.

Okay; perhaps the warning should be printed in more circumstances.

> In any case, we use other tools to ensure that the code works with JDK 1.6 (e.g. animal-sniffer plugin) and our final release versions of Lucene are compiled and release binaries created using JDK6. But some people may still want to compile the code with recent Java versions, including JDK8.
> This is clearly a backwards break and a regression, sorry. With Oracle's current practice to stop supporting older JDKs (like Java 6 from now on),

JDK 6 first shipped in 2006 and JDK 6 had its end of public updates from 
Oracle delayed twice, so JDK 6 is hardly being rushed off the stage!

> how can anybody with a recent JDK compile this open source project (without crazy bootclasspath tricks, just to compile it)?

The "crazy bootclasspath trick" has been the recommend practice in this 
situation and documented in the javac manpage for at least the last 10 
years (see the 1.4.2 man page for javac

I've personally closed several bugs filed against the JDK along the 
lines of "I compiled with -source OLD -target OLD and it didn't work on 
JDK OLD" because the compiled code referenced methods added since JDK 
OLD. Setting the bootclasspath prevents exactly this problem and is in 
general required for correct cross compile.

>   If this does no longer work at all, you can nuke -source and -target from the possible javac cmd-line options.

Well, we have no plans to get rid of the source and target options, but 
neither are we obliged by the Java SE specification to support them and 
they do add some complication to maintaining the compiler. As a 
historical note, javac did not have a -source option until the JDK 1.4.x 

It was important at that point to help manage the addition of the 
"assert" keyword to the language.


> I will open a new bug report on and hope for an "official" response.
> Uwe
> -----
> Uwe Schindler
> uschindler at
> Apache Lucene PMC Member / Committer
> Bremen, Germany
>> -----Original Message-----
>> From: Joe Darcy [mailto:joe.darcy at]
>> Sent: Thursday, February 28, 2013 10:17 PM
>> To: Uwe Schindler
>> Cc: compiler-dev at; lambda-dev at
>> Subject: Re: Regression in JDK8 build 78: javac complains about missing
>> Class#isAnnotationPresent
>> Hello Uwe,
>> One of the warnings you should have received from javac is JDK 8 is
>> something along the lines of "using -source 6 without setting -
>> bootclasspath."
>> If follow this long-standing recommendation,
>> then your existing code should compile.
>> Thanks for trying out the JDK 8 builds on Lucene,
>> -Joe
>> On 2/28/2013 1:07 PM, Uwe Schindler wrote:
>>> Hi,
>>> we tried to build Apache Lucene with JDK8 b78  today (Java(TM) SE
>> Runtime Environment (build 1.8.0-ea-b78)), so we can use the new features
>> of e.g. doclint on javac and javadocs (see related mails on javadoc-
>> dev at Unfortunately those bugs are fixed, but suddenly,
>> the source code of Apache Lucene and Apache Solr no longer compiles,
>> although valid in JDK6, JDK7 and earlier JDK8 builds. We get the following
>> error:
>>>       [javac] Compiling 113 source files to C:\Users\Uwe
>> Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-
>> framework\classes\java
>>>       [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-
>> lusolr3\lucene\test-
>> framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClass
>> error: cannot find symbol
>>>       [javac]     if (targetClass.isAnnotationPresent(SuppressCodecs.class)) {
>>>       [javac]                    ^
>>>       [javac]   symbol:   method isAnnotationPresent(Class<SuppressCodecs>)
>>>       [javac]   location: variable targetClass of type Class<?>
>>>       [javac] Note: Some input files use or override a deprecated API.
>>>       [javac] Note: Recompile with -Xlint:deprecation for details.
>>>       [javac] 1 error
>>> This method exists since Java 5, but a recent commit in JDK 8
>> ( seems to
>> cause this. The implementations were removed from the concrete classes,
>> only the new default implementation on the interface should be used.
>> Unfortunately, the compiler (javac) does not understand this and fails to
>> compile. -target and -source is 1.6.
>>> >From the javadocs issues I know that currently the response times on
>> new bugs on is > 3 weeks, so I contact you directly.
>>> Please include my eMail address into the responses, as I am not
>>> subscribed to both lists,
>>> Uwe
>>> -----
>>> Uwe Schindler
>>> uschindler at
>>> Apache Lucene PMC Member / Committer
>>> Bremen, Germany

More information about the compiler-dev mailing list