[
https://issues.apache.org/jira/browse/HADOOP-13410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616434#comment-15616434
]
Matt Motter commented on HADOOP-13410:
--------------------------------------
I realize this issue has already been resolved, but this muddies the waters a
bit for users who leverage an uber jar with AOT compilation. This is because
the unpacked jar modifies time stamps to when the command is running. Doing so
causes timestamps for .clj files and there respective class files to have the
same timestamp, which causes Clojure to always dynamically recompile the source.
In previous releases the original jar was being added to the class path after
the unpacked jar. It would have been more benefical for users if the original
jar was added before the unpacked jar so its class files would have been
leveraged over the now updated class files within the unpacked jar. The only
work around to this is to specify the original jar on the HADOOP_CLASSPATH and
set HADOOP_USER_CLASSPATH_FIRST true, which most users tend to forget to do and
just becomes added work to run commands.
> RunJar adds the content of the jar twice to the classpath
> ---------------------------------------------------------
>
> Key: HADOOP-13410
> URL: https://issues.apache.org/jira/browse/HADOOP-13410
> Project: Hadoop Common
> Issue Type: Bug
> Components: util
> Reporter: Sangjin Lee
> Assignee: Yuanbo Liu
> Attachments: HADOOP-13410.001.patch
>
>
> Today when you run a "hadoop jar" command, the jar is unzipped to a temporary
> location and gets added to the classloader.
> However, the original jar itself is still added to the classpath.
> {code}
> List<URL> classPath = new ArrayList<>();
> classPath.add(new File(workDir + "/").toURI().toURL());
> classPath.add(file.toURI().toURL());
> classPath.add(new File(workDir, "classes/").toURI().toURL());
> File[] libs = new File(workDir, "lib").listFiles();
> if (libs != null) {
> for (File lib : libs) {
> classPath.add(lib.toURI().toURL());
> }
> }
> {code}
> As a result, the contents of the jar are present in the classpath *twice* and
> are completely redundant. Although this does not necessarily cause
> correctness issues, some stricter code written to require a single presence
> of files may fail.
> I cannot think of a good reason why the jar should be added to the classpath
> if the unjarred content was added to it. I think we should remove the jar
> from the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
