[
https://issues.apache.org/jira/browse/HADOOP-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125742#comment-14125742
]
Todd Lipcon commented on HADOOP-11064:
--------------------------------------
sorry, hit send too early:
Doing a fix to maintain the old private API is certainly an easy option like
you suggested, but it would be nice to have this compatibility guarantee
written down somewhere if we feel it is something we want to maintain. I'm -0
on guaranteeing support for mixed version classpaths, since the testing matrix
becomes quite large, and it means that *internal* APIs (these methods are
marked InterfaceAudience.Private) now need attention with regard to
compatibility. What distinguishes the shared library case from the mixed
hdfs/common case mentioned above?
> UnsatisifedLinkError with hadoop 2.4 JARs on hadoop-2.6 due NativeCRC32
> method changes
> --------------------------------------------------------------------------------------
>
> Key: HADOOP-11064
> URL: https://issues.apache.org/jira/browse/HADOOP-11064
> Project: Hadoop Common
> Issue Type: Bug
> Components: native
> Affects Versions: 2.6.0
> Environment: Hadoop 2.6 cluster, trying to run code containing hadoop
> 2.4 JARs
> Reporter: Steve Loughran
> Priority: Blocker
>
> The private native method names and signatures in {{NativeCrc32}} were
> changed in HDFS-6561 ... as a result hadoop-common-2.4 JARs get unsatisifed
> link errors when they try to perform checksums.
> This essentially stops Hadoop 2.4 applications running on Hadoop 2.6 unless
> rebuilt and repackaged with the hadoop- 2.6 JARs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
