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
