[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] API Breakage(-ish) in 3.6 M6 ?

That's only a problem for source compatibility in 3.6. At run time, the addition of a public TitleAreaDialog#getMessage() doesn't matter for existing subclasses, see
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.7

You should make the methods public in the overriding classes. That will be source and binary compatible with both 3.5 and 3.6.

HTH,
Markus


From: Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date: 2010-03-18 23:32
Subject: [platform-ui-dev] API Breakage(-ish) in 3.6 M6 ?





>From eclipse.platform.jface

Hi,

I'm adopting the Helios M6 milestone of a variety of Eclipse
components that I use and have run into a source-incompatible change
in the TitleAreaDialog class:  a public method getMessage() was added
that clashes with protected methods that some of my subclasses already
had defined.  The similar addition of getErrorMessage() was not a
problem for me.  :-)

I can understand that it makes sense to add these methods to mirror
the long-standing public setters, and it seems to be a case of the
obvious API addition exception that is discussed on the wiki:

http://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method

but I am concerned about compatibility of Eclipse 3.6 with my existing
plug-ins.  If my users update to 3.6 without updating my plug-ins (I
may not have a new release by that time), what will happen?  Will my
dialog classes that define protected methods that now override the
public getMessage() method be well-defined, JLS-wise (more
importantly, JVM-wise)?  Or will my users be faced with linkage
errors?

I have no problem updating my code to make my implementations of these
methods public (or, more likely, delete them) but I am concerned about
upgradeability.

Thanks,

Christian



--
Paul Webster
Hi floor.  Make me a sammich! - GIR
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev