[
https://issues.apache.org/jira/browse/HADOOP-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036951#comment-13036951
]
Allen Wittenauer commented on HADOOP-6605:
------------------------------------------
My technical objection is that there is a high likelihood of getting this wrong.
For example, we should have a check to make sure that the java we find is
actually 1.6.x. We need a check to make sure that the java we find actually
works properly (i.e., I believe it was _18 or so that caused us issues). We
have to make the determination if we want to allow heterogenous JREs. What
if /usr/java/x isn't a Sun Java?
The wildcard generates a whole spate of problems. Do we always pick the oldest
version? Do we reverse the regex and grab the newest? No matter what we do
there, this is going to cause major problems with those that want to do staged
rollouts of new JREs.
No, the "but you can always set it" is not an excuse for allowing surprising
behavior.
...
Again: This is way too much work to shove into the interactive hadoop
commands. Until this moves out into a one-time setup, my binding -1 will
remain.
> Add JAVA_HOME detection to hadoop-config
> ----------------------------------------
>
> Key: HADOOP-6605
> URL: https://issues.apache.org/jira/browse/HADOOP-6605
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Chad Metcalf
> Assignee: Eli Collins
> Priority: Minor
> Fix For: 0.22.0
>
> Attachments: HADOOP-6605.patch, hadoop-6605-1.patch,
> hadoop-6605-2.patch
>
>
> The commands that source hadoop-config.sh currently bail with an error if
> JAVA_HOME is not set. Let's detect JAVA_HOME (from a list of locations on
> various OS types) if JAVA_HOME is not already set by hadoop-env.sh or the
> environment. This way users don't have to manually configure it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
