Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # user >> 0.21 found interface but class was expected


Copy link to this message
-
Re: 0.21 found interface but class was expected
On Sat, Nov 13, 2010 at 9:50 PM, Todd Lipcon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>> 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 <
>> >> > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>> >> > > >
>> >> > > >
>> >> > > >  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

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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB