Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 22 Mar 2013 22:45:15 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12634789.1362135040848.40425.1363992315276@arcas>
In-Reply-To: <JIRA.12634789.1362135040848@arcas>
References: <JIRA.12634789.1362135040848@arcas>
Subject: [jira] [Resolved] (LUCENE-4808) Add workaround for a JDK 8 "class
 library bug" which is still under discussion and may *not* be fixed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/LUCENE-4808?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler resolved LUCENE-4808.
-----------------------------------

    Resolution: Fixed

This bug was fixed in Java 8 build 82. I reverted the workaround.
               =20
> Add workaround for a JDK 8 "class library bug" which is still under discu=
ssion and may *not* be fixed
> -------------------------------------------------------------------------=
----------------------------
>
>                 Key: LUCENE-4808
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4808
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: general/build
>    Affects Versions: 4.1, 5.0
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>         Attachments: LUCENE-4808.patch, LUCENE-4808.patch
>
>
> With JDK8 build 78 there was introduced a backwards compatibility regress=
ion which may not be fixed until release, because Oracle is possibly accept=
ing this backwards break regarding cross-compilation to JDK6.
> The full thread on the OpenJDK mailing list: [http://mail.openjdk.java.ne=
t/pipermail/compiler-dev/2013-February/005737.html] (continues in next mont=
h: http://mail.openjdk.java.net/pipermail/compiler-dev/2013-March/005748.ht=
ml)
> *In short:* JDK 8 adds so called default implementations on interfaces (m=
eans you can add a new method to an interface and provide a "default" imple=
mentation, so code implementing this interface is not required to implement=
 the new method. This is really cool and would also help Lucene to make use=
 of Interfaces instead of abstract classes which don't allow polymorphism).
> In Lucene we are still compatible with Java 7 and Java 6. So like million=
s of other open source projects, we use "-source 1.6 -target 1.6" to produc=
e class files which are Java 1.6 conform, although you use a newer JDK to c=
ompile. Of course this approach has problem (e.g. if you use older new meth=
ods, not available in earliert JDKs). Because of this we must at least comp=
ile Lucene with a JDK 1.6 legacy JDK and also release the class files with =
this version. For 3.6, the RM has to also install JDK 1.5 (which makes it i=
mpossible to do this on Mac). So -source/-target is a alternative to at lea=
st produce 1.6/1.5 compliant classes. According to Oracle, this is *not* th=
e correct way to do this: Oracle says, you have to use: -source, -target an=
d -Xbootclasspath to really crosscompile -> and the last thing is what brea=
ks here. To correctly set the bootclasspath, you need to have an older JDK =
installed or you should be able to at least download it from maven (which i=
s not available to my knowledge).
> The problem with JDK8 is now: If you compile with -source/-target but not=
 the bootclasspath, it happens that the compiler does no longer understand =
new JDK8 class file structures in the new rt.jar, so producing compile fail=
ures. In the case of this bug: AnnotatedElement#isAnnotationPresent() exist=
s since Java 1.5 in the interface, but all implementing classes have almost=
 the same implementation: "return getAnnotation(..) !=3D null;". So the des=
igners of the class library decided to move that method as so called defaul=
t method into the interface itsself, removing code duplication. If you then=
 compile code with "-source 1.6 -target 1.6" using that method, the javac c=
ompier does not know about the new default method feature and simply says: =
"Method not found in java.lang.Class":
> {noformat}
>     [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\t=
est-framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClassE=
nv.java:134: 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
> {noformat}
> But until the Oracle people have a good workaround (I suggested to still =
implement the method on the implementation classes like Class/Method/... bu=
t delegate to the interface's default impl), we can quickly commit a replac=
ement of this broken method call by (getAnnotation(..) !=3D null). I want t=
o do this, so we can enable jenkins builds with recent JDK 8 again.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org