[
https://issues.apache.org/jira/browse/HADOOP-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443328#comment-13443328
]
Steve Loughran commented on HADOOP-8737:
----------------------------------------
I don't think this will always work.
{{JAVA_HOME}} is often set to JVM-home, whereas if you want jni.h then you need
{{JDK_HOME}}, which is not so formally defined.
Maven, Ant, etc find {{JAVA_HOME}} from whatever env variable is defined,
falling back to some guesswork -but they are often happy with just the JRE.
Assuming that {{JAVA_HOME}} always points to a JDK with the jni.h file in a
specific subdir is very brittle. At the least, the logic should use a JDK_HOME
env var which would be set to JAVA_HOME iff the env var had not already been
set.
> cmake: always use JAVA_HOME to find libjvm.so, jni.h, jni_md.h
> --------------------------------------------------------------
>
> Key: HADOOP-8737
> URL: https://issues.apache.org/jira/browse/HADOOP-8737
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
> Affects Versions: 2.2.0-alpha
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Priority: Minor
> Attachments: HADOOP-8737.001.patch
>
>
> We should always use the {{libjvm.so}}, {{jni.h}}, and {{jni_md.h}} under
> {{JAVA_HOME}}, rather than trying to look for them in system paths. Since we
> compile with Maven, we know that we'll have a valid {{JAVA_HOME}} at all
> times. There is no point digging in system paths, and it can lead to host
> contamination if the user has multiple JVMs installed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
