Oh, thank you Todd! For a second there I thought that Hadoop developers have promised a full binary compatibility (in true Solaris sense of the word).
Now I understand that such thing never been promised. Even though Hadoop haven't come over 'major' version change yet. Seriously. Steve, you are talking about leaving and breathing system here. To best of my understanding first stable Hadoop version was suppose to be 1.0 - a major version according to your own terms. Which apparently hasn't came around yet. Now, what exactly you are frustrated about? Cos On Sat, Nov 13, 2010 at 06:50PM, Todd Lipcon 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
signature.asc
Description: Digital signature
