hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-14586) org.apache.hadoop.util.Shell in 2.7 breaks <clinit> on Java 9 RC build; backport HADOOP-10775 to 2.7.x
Date Mon, 26 Jun 2017 17:22:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-14586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063450#comment-16063450

Uwe Schindler commented on HADOOP-14586:

I would not backport anything. Just change the line to return true in 2.7.x. At least remove
the substring(0,2) from it, This is useless and has no effect on the result of the compareTo
The problem we have is:
- Solr claims to be compatible to Java 9 (already in the 6.x branch). And in fact it is, unless
you somehow hit the class accidentally by adding a HdfsDirectoryFactory to your config. It
then breaks (it is enough to have it in the "example" config).
- The fix is easy and we cannot upgrade to 2.8.x in the existing bugfix branch (Solr 6.6)
- For master (coming 7.0, we are working on fixing this).

If we cannot fix this easily, we would fork the Hadoop 2.7 branch and make a solr-private
release on Maven Central with just the one line changed, so we can fix this serious bug -
and I don't like this to happen. It has in reality nothing to do with Java 9, it is just that
some code in a static initializer applies an operation on a string that comes from the outside
without correct bounds checks. This is a bug that may happen in any Java version out there,
not only 9. Think of custom builds of OpenJDK.

>  org.apache.hadoop.util.Shell in 2.7 breaks <clinit> on Java 9 RC build; backport
HADOOP-10775 to 2.7.x
> -------------------------------------------------------------------------------------------------------
>                 Key: HADOOP-14586
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14586
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: common
>    Affects Versions: 2.7.2
>         Environment: Java 9, build 175 (Java 9 release candidate as of June 25th, 2017)
>            Reporter: Uwe Schindler
>            Assignee: Akira Ajisaka
>            Priority: Blocker
>              Labels: Java9, release-blocker
>         Attachments: HADOOP-14586-branch-2.7-01.patch
> You cannot use any Hadoop component anymore with the latest release candidate build of
Java 9, because it fails with an StringIndexOutOfBoundsException in {{org.apache.hadoop.util.Shell#<clinit>}}.
This leads to a whole cascade of failing classes (next in chain is StringUtils).
> The reason is that the release candidate build of Java 9 no longer has "-ea" in the version
string and the system property "java.version" is now simply "9". This causes the following
line to fail fatally:
> {code:java}
>   private static boolean IS_JAVA7_OR_ABOVE =
>       System.getProperty("java.version").substring(0, 3).compareTo("1.7") >= 0;
> {code}
> Analysis:
> - This code looks wrong, as comparing a version this way is incorrect.
> - The {{substring(0, 3)}} is completely useless, {{compareTo}} also works without it,
although it is still an invalid way to compare a version.
> Maybe look at Lucene's source code (Constants.java) to have a better way in doing this!
Sorry this is incredible to me! Hardcoding string bounds into a static initializer that are
applied on a string that you have no control of...
> This issue breaks Apache Solr from working with Java 9, so I set it to "critical". We
have to disable the whole Hadoop integration once Java 9 is detected.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message