[
https://issues.apache.org/jira/browse/HADOOP-14586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063450#comment-16063450
]
Uwe Schindler edited comment on HADOOP-14586 at 6/26/17 5:24 PM:
-----------------------------------------------------------------
Hi,
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 call.
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 or Kerberos Authentication 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 Lucene/Solr 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.
was (Author: thetaphi):
Hi,
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 call.
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 Lucene/Solr 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
