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

Uwe Schindler uschindler at apache.org
Fri Mar 1 00:11:46 PST 2013


Hi Jon,

> I think you have a good point here.
> 
> This is not so much a compiler issue as a compatibility issue regarding changes
> to an API.

This was my first idea, too and I agree. The new "default" interface methods are a good solution for otherwise backwards incompatible API changes on interfaces. This will make use of interfaces especially in open-source projects again more suitable, because the big issue of adding new methods to interfaces making your library no longer compatible to old interface implementations is easily solved.

The problem here is:
- The problematic method isAnnotationPresent() was existing since Java 1.5 and was part of the interface from the beginning. The change made in this commit was more a "class library code cleanup" than an approach to keep backwards (because the method existed since the beginning of the AnnotatedElement interface, so using a default interface method implementation is not really appropriate here).
- Because the error did not exist when I ran the classes compiled with real JDK 1.6 against the Java 8 runtime, the "backwards layer to support old class file formats in the Java 8 runtime" works fine, only javac with "-source 1.6" fails to compile
- The new default interface methods are not a problem for users compiling with -source 1.6, because when they are only used to add default implementations to older interfaces, the user will not have those method calls in his source code.

I would really suggest to simply "revert" the change in http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e04467fa13af - and possibly at other places in the JDK source code where a similar change was made (I only found the isAnnotationPresent() problem with our source code, but there may be more). You would make lots of projects happy that are actually using this method.

To work around the problem in Lucene's source code, we can commit a "workaround" (suggested by Robert Muir), to don't use the method and do "if (class.getAnnotation(..) != null)". But We are for sure not the only open source project affected by this (e.g. JUnit 4 may no longer compile,... -> it also uses -source/-target 1.5).

> The problem in this case is that the impl of a method was *moved* to being a
> default method on an interface.  A safer, more compatible solution would
> have been to have added the method to the interface but not delete it from
> its original location.

I agree, the interface and method was always there (since 1.5), so adding this method as a "default" method was just a code cleanup (move the code from the implementing classes to the interface) and not an API improvement. As mentioned before, I would revert the whole commit.

Thanks,
Uwe

> -- Jon
> 
> 
> On 02/28/2013 02:36 PM, Uwe Schindler wrote:
> > Thanks Maurizio,
> >
> >
> >
> > that’s true, somebody added the –Xlint:-options tot he ANT build file.
> >
> >
> >
> > This is still no answer to the source of the problem, making again a new
> Oracle Java version unusable to compile millions of open source projects
> (Lucene is just an example) – this status quo seems to repeat on every new
> major version. Last time it was the serious Hotspot bug corrumpting loops in
> Java7 GA. Every public Java project has somewhere in their build file “-target
> 1.6 -source 1.6” (or another older version), because otherwise you cannot
> run the generated class files with older Java versions. Compiling with a
> custom bootclasspath is a good idea to *validate* that your code actually is
> compliant. But if you need to use the bootclasspath, you need to have the
> older JDK version installed - in that case you could compile with it, too.
> >
> >
> >
> > The intention here is to just “test” the class files with newer JDK versions
> which is now impossible, without hacking the whole build in an incompatible
> way. If this is not fixed, we will suggest to users, not to upgrade to JDK8 once
> it is out – because we cannot test the class files with JDK 8 (and we have
> already seen lots of hotspot issues making Apache Lucene crash/fail). The
> same procedure as every year – ahm Java version.
> >
> >
> >
> > Of course to produce Java 6 class file format, one could use only “-target
> 1.6” and don’t pass “-source 1.6” (so let it default to 1.8), but this does not
> help if you build your project with Apache Ant (maybe doesn’t help with
> Maven, too):
> >
> >
> >
> >     [javac] Compiling 113 source files to C:\Users\Uwe
> > Schindler\Projects\lucene\trunk-lusolr3\lucene\build\test-framework\cl
> > asses\java
> >
> >      [javac]
> >
> >      [javac]           WARNING
> >
> >      [javac]
> >
> >      [javac] The -source switch defaults to 1.8 in JDK 1.8.
> >
> >      [javac] If you specify -target 1.6 you now must also specify -source 1.6.
> >
> >      [javac] Ant will implicitly add -source 1.6 for you.  Please change your
> build file.
> >
> >
> >
> > So you no longer have the chance to produce javac 1.6 compliant class files
> without bootclasspath (using common build tools like Apache ANT). This
> makes JDK8 unusable.
> >
> >
> >
> > Sorry for complaining,
> >
> > But that’s a major regression!
> >
> >
> >
> > Uwe
> >
> >
> >
> > -----
> >
> > Uwe Schindler
> >
> > uschindler at apache.org
> >
> > Apache Lucene PMC Member / Committer
> >
> > Bremen, Germany
> >
> > http://lucene.apache.org/
> >
> >
> >
> > From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com]
> > Sent: Thursday, February 28, 2013 11:15 PM
> > To: Uwe Schindler
> > Cc: 'Joe Darcy'; lambda-dev at openjdk.java.net;
> > compiler-dev at openjdk.java.net
> > Subject: Re: Regression in JDK8 build 78: javac complains about
> > missing Class#isAnnotationPresent
> >
> >
> >
> > On 28/02/13 21:31, Uwe Schindler wrote:
> >
> > 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.
> >
> > This warning is a Xlint warning - so it's possible that you are compiling the
> project with a custom set of Xlint warnings that doesn't include this category
> (called 'options').
> >
> > Maurizio
> >
> >



More information about the lambda-dev mailing list