[
https://issues.apache.org/jira/browse/HDFS-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130979#comment-14130979
]
Christopher Tubbs commented on HDFS-7040:
-----------------------------------------
To the comment about bumping the Guava version in 2.7, I think that's
reasonable, but I really hope something can be done about the MAPREDUCE-6083
for 2.6.0, because that's a much more serious manifestation of this same issue
(because it shows up in client code paths, and not just server/MiniDFS code
paths). Whatever action is taken for that issue, could be applied here as well,
at least in 2.6.0, if not all the way back to 2.4.0.
> 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)
