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

Uwe Schindler created LUCENE-4808:
-------------------------------------

             Summary: Add workaround for a JDK 8 "class library bug" which =
is still under discussion any 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


With JDK8 build 78 there was introduced a backwards compatibility regressio=
n which may not be fixed until release, because Oracle is possibly acceptin=
g this backwards break regarding cross-compilation to JDK6.

The full thread on the OpenJDK mailing list: [http://mail.openjdk.java.net/=
pipermail/compiler-dev/2013-February/005737.html] (continues in next month:=
 http://mail.openjdk.java.net/pipermail/compiler-dev/2013-March/005748.html=
)

*In short:* JDK 8 adds so called default implementations on interfaces (mea=
ns you can add a new method to an interface and provide a "default" impleme=
ntation, so code implementing this interface is not required to implement t=
he new method. This is really cool and would also help Lucene to make use o=
f Interfaces instead of abstract classes which don't allow polymorphism).

In Lucene we are still compatible with Java 7 and Java 6. So like millions =
of other open source projects, we use "-source 1.6 -target 1.6" to produce =
class files which are Java 1.6 conform, although you use a newer JDK to com=
pile. Of course this approach has problem (e.g. if you use older new method=
s, not available in earliert JDKs). Because of this we must at least compil=
e Lucene with a JDK 1.6 legacy JDK and also release the class files with th=
is version. For 3.6, the RM has to also install JDK 1.5 (which makes it imp=
ossible to do this on Mac). So -source/-target is a alternative to at least=
 produce 1.6/1.5 compliant classes. According to Oracle, this is *not* the =
correct way to do this: Oracle says, you have to use: -source, -target and =
-Xbootclasspath to really crosscompile -> and the last thing is what breaks=
 here. To correctly set the bootclasspath, you need to have an older JDK in=
stalled or you should be able to at least download it from maven (which is =
not available to my knowledge).

The problem with JDK8 is now: If you compile with -source/-target but not t=
he bootclasspath, it happens that the compiler does no longer understand ne=
w JDK8 class file structures in the new rt.jar, so producing compile failur=
es. In the case of this bug: AnnotatedElement#isAnnotationPresent() exists =
since Java 1.5 in the interface, but all implementing classes have almost t=
he same implementation: "return getAnnotation(..) !=3D null;". So the desig=
ners of the class library decided to move that method as so called default =
method into the interface itsself, removing code duplication. If you then c=
ompile code with "-source 1.6 -target 1.6" using that method, the javac com=
pier does not know about the new default method feature and simply says: "M=
ethod not found in java.lang.Class":

{noformat}
    [javac] Compiling 113 source files to C:\Users\Uwe Schindler\Projects\l=
ucene\trunk-lusolr3\lucene\build\test-framework\classes\java
    [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\tes=
t-framework\src\java\org\apache\lucene\util\TestRuleSetupAndRestoreClassEnv=
.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 im=
plement the method on the implementation classes like Class/Method/... but =
delegate to the interface's default impl), we can quickly commit a replacem=
ent of this broken method call by (getAnnotation(..) !=3D null). I want to =
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