On Sat, Nov 13, 2010 at 9:50 PM, Todd Lipcon <t...@cloudera.com> wrote: > We do have policies against breaking APIs between consecutive major versions > except for very rare exceptions (eg UnixUserGroupInformation went away when > security was added). > > We do *not* have any current policies that existing code can work against > different major versions without a recompile in between. Switching an > implementation class to an interface is a case where a simple recompile of > the dependent app should be sufficient to avoid issues. For whatever reason, > the JVM bytecode for invoking an interface method (invokeinterface) is > different than invoking a virtual method in a class (invokevirtual). > > -Todd > > On Sat, Nov 13, 2010 at 5:28 PM, Lance Norskog <goks...@gmail.com> wrote: > >> It is considered good manners :) >> >> Seriously, if you want to attract a community you have an obligation >> to tell them when you're going to jerk the rug out from under their >> feet. >> >> On Sat, Nov 13, 2010 at 3:27 PM, Konstantin Boudnik <c...@apache.org> >> wrote: >> > It doesn't answer my question. I guess I will have to look for the answer >> somewhere else.... >> > >> > On Sat, Nov 13, 2010 at 03:22PM, Steve Lewis wrote: >> >> Java libraries are VERY reluctant to change major classes in a way that >> >> breaks backward compatability - >> >> NOTE that while the 0.18 packages are deprecated, they are separate >> from >> >> the 0.20 packages allowing >> >> 0.18 code to run on 0.20 systems - this is true of virtually all Java >> >> libraries >> >> >> >> On Sat, Nov 13, 2010 at 3:08 PM, Konstantin Boudnik <c...@apache.org> >> wrote: >> >> >> >> > As much as I love ranting I can't help but wonder if there were any >> >> > promises >> >> > to make 0.21+ be backward compatible with <0.20 ? >> >> > >> >> > Just curious? >> >> > >> >> > On Sat, Nov 13, 2010 at 02:50PM, Steve Lewis wrote: >> >> > > I have a long rant at http://lordjoesoftware.blogspot.com/ on this >> but >> >> > > the moral is that there seems to have been a deliberate decision >> that >> >> > 0,20 >> >> > > code will may not be comparable with - >> >> > > I have NEVER seen a major library so directly abandon backward >> >> > compatability >> >> > > >> >> > > >> >> > > On Fri, Nov 12, 2010 at 8:04 AM, Sebastian Schoenherr < >> >> > > sebastian.schoenh...@student.uibk.ac.at> wrote: >> >> > > >> >> > > > Hi Steve, >> >> > > > we had a similar problem. We've compiled our code with version >> 0.21 but >> >> > > > included the wrong jars into the classpath. (version 0.20.2; >> >> > > > NInputFormat.java). It seems that Hadoop changed this class to an >> >> > interface, >> >> > > > maybe you've a simliar problem. >> >> > > > Hope this helps. >> >> > > > Sebastian >> >> > > > >> >> > > > >> >> > > > Zitat von Steve Lewis <lordjoe2...@gmail.com>: >> >> > > > >> >> > > > >> >> > > > Cassandra sees this error with 0.21 of hadoop >> >> > > >> >> >> > > >> Exception in thread "main" >> java.lang.IncompatibleClassChangeError: >> >> > Found >> >> > > >> interface org.apache.hadoop.mapreduce.JobContext, but class was >> >> > expected >> >> > > >> >> >> > > >> I see something similar >> >> > > >> Error: Found interface >> >> > org.apache.hadoop.mapreduce.TaskInputOutputContext, >> >> > > >> but class was expected >> >> > > >> >> >> > > >> I find this especially puzzling >> >> > > >> since org.apache.hadoop.mapreduce.TaskInputOutputContext IS a >> class >> >> > not an >> >> > > >> interface >> >> > > >> >> >> > > >> Does anyone have bright ideas??? >> >> > > >> >> >> > > >> -- >> >> > > >> Steven M. Lewis PhD >> >> > > >> 4221 105th Ave Ne >> >> > > >> Kirkland, WA 98033 >> >> > > >> 206-384-1340 (cell) >> >> > > >> Institute for Systems Biology >> >> > > >> Seattle WA >> >> > > >> >> >> > > >> >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > > -- >> >> > > Steven M. Lewis PhD >> >> > > 4221 105th Ave Ne >> >> > > Kirkland, WA 98033 >> >> > > 206-384-1340 (cell) >> >> > > Institute for Systems Biology >> >> > > Seattle WA >> >> > >> >> > -----BEGIN PGP SIGNATURE----- >> >> > Version: GnuPG v1.4.10 (GNU/Linux) >> >> > >> >> > iF4EAREIAAYFAkzfGnwACgkQenyFlstYjhK6RwD+IdUVZuqXACV9+9By7fMiy/MO >> >> > Uxyt4o4Z4naBzvjMu0cBAMkHLuHFHxuM5Yzb7doeC8eAzq+brsBzVHDKGeUD5FG4 >> >> > =dr5x >> >> > -----END PGP SIGNATURE----- >> >> > >> >> > >> >> >> >> >> >> -- >> >> Steven M. Lewis PhD >> >> 4221 105th Ave Ne >> >> Kirkland, WA 98033 >> >> 206-384-1340 (cell) >> >> Institute for Systems Biology >> >> Seattle WA >> > >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.10 (GNU/Linux) >> > >> > iF4EAREIAAYFAkzfHswACgkQenyFlstYjhKtUAD+Nu/gL5DQ+v9iC89dIaHltvCK >> > Oa6HOwVWNXWksUxhZhgBAMueLiItX6y4jhCKA5xCOqAmfxA0KZpTkyZr4+ozrazg >> > =wScC >> > -----END PGP SIGNATURE----- >> > >> > >> >> >> >> -- >> Lance Norskog >> goks...@gmail.com >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
Cloudera and Yahoo have back ported the interesting security components and some enhancements into their 0.20 based distributions. Out of the box, I know hive does not (yet) work with 0.21. I imagine other tools have minor problems as well. I have not read anything about the "big players" looking to move to 0.21. These factors and other make it unclear what the adoption of 0.21.X will be. The way I look at it I am not very compelled to go 20->21 when everything interesting is back ported and the only thing I lose seems to be compatibility.
