[ 
https://issues.apache.org/jira/browse/HDFS-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131641#comment-14131641
 ] 

Sean Busbey commented on HDFS-7040:
-----------------------------------

FWIW, HBase currently has a copied reimplementation of LimitedInputStream 
(since HBASE-9667) for this same reason.

> 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)

Reply via email to