[
https://issues.apache.org/jira/browse/HDFS-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202856#comment-14202856
]
Christopher Tubbs commented on HDFS-7040:
-----------------------------------------
I added a patch to fix this under MAPREDUCE-6083 for versions 2.6.0 and later
which doesn't change the Guava version dependency. I suppose it could be
back-ported to earlier versions (2.4/2.5), but it's probably not worth it since
those versions are really only affected by {{MiniDFSCluster}}, and that's very
limited.
> HDFS dangerously uses @Beta methods from very old versions of Guava
> -------------------------------------------------------------------
>
> Key: HDFS-7040
> URL: https://issues.apache.org/jira/browse/HDFS-7040
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.4.0, 2.5.0, 2.4.1
> Reporter: Christopher Tubbs
> Labels: beta, deprecated, guava
> Attachments: 0001-HDFS-7040-Avoid-beta-LimitInputStream-in-Guava.patch
>
>
> HDFS uses LimitInputStream from Guava. This was introduced as @Beta and is
> risky for any application to use.
> The problem is further exacerbated by Hadoop's dependency on Guava version
> 11.0.2, which is quite old for an active project (Feb. 2012).
> Because Guava is very stable, projects which depend on Hadoop and use Guava
> themselves, can use up through Guava version 14.x
> However, in version 14, Guava deprecated LimitInputStream and provided a
> replacement. Because they make no guarantees about compatibility about @Beta
> classes, they removed it in version 15.
> What should be done: Hadoop should updated its dependency on Guava to at
> least version 14 (currently Guava is on version 19). This should have little
> impact on users, because Guava is so stable.
> HDFS should then be patched to use the provided alternative to
> LimitInputStream, so that downstream packagers, users, and application
> developers requiring more recent versions of Guava (to fix bugs, to use new
> features, etc.) will be able to swap out the Guava dependency without
> breaking Hadoop.
> Alternative: While Hadoop cannot predict the marking and removal of
> deprecated code, it can, and should, avoid the use of @Beta classes and
> methods that do not offer guarantees. If the dependency cannot be bumped,
> then it should be relatively trivial to provide an internal class with the
> same functionality, that does not rely on the older version of Guava.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
