Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # user - 0.21 found interface but class was expected
Steve Lewis
2010-11-11, 21:02
Sebastian Schoenherr
2010-11-12, 16:04
Steve Lewis
2010-11-13, 22:50
Konstantin Boudnik
2010-11-13, 23:08
Steve Lewis
2010-11-13, 23:22
Konstantin Boudnik
2010-11-13, 23:27
Lance Norskog
2010-11-14, 01:28
Todd Lipcon
2010-11-14, 02:50
Edward Capriolo
2010-11-14, 03:19
Konstantin Boudnik
2010-11-14, 06:41
Allen Wittenauer
2010-11-14, 08:05
Allen Wittenauer
2010-11-14, 08:08
Steve Loughran
2010-11-16, 12:51
Copy link to this message
-
Re: 0.21 found interface but class was expected
Tom White 2010-11-15, 19:13
Hi Steve,

Sorry to hear about the problems you had. The issue you hit was a
result of MAPREDUCE-954, and there was some discussion on that JIRA
about compatibility. I believe the thinking was that the context
classes are framework classes, so users don't extend/implement them in
the normal course of use, and it's also understood that users would
recompile their apps (i.e. source compatibility). However, tools like
MRUnit which extend/implement these classes do need to be updated when
a change like this happens.

We tried hard to make 0.21 as backwards compatible with 0.20 as
possible, a big part of which was going through all the APIs and
annotating their audience and stability (see
http://developer.yahoo.com/blogs/hadoop/posts/2010/05/towards_enterpriseclass_compat/
for background). The new MapReduce API (in
org.apache.hadoop.mapreduce), which is what we are talking about here,
is not yet declared stable (unlike the old API) and these classes are
marked with @InterfaceStability.Evolving to show that they can change
even between minor releases. I think we could improve visibility to
users by publishing a list of incompatible changes in the API for each
release - so I've opened HADOOP-7035 for this.

Cheers,
Tom

On Sun, Nov 14, 2010 at 7:41 AM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> 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 <[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