[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 ?

The difference between source compatibility and binary compatibility is probably not immediately obvious to everybody.

Here is a quote from http://wiki.eclipse.org/Evolving_Java-based_APIs (see http://wiki.eclipse.org/API_Central for other relevant material) that explains it:

"While the idea that the Java source code for existing Clients should continue to compile without errors against the revised Component API, this is not strictly necessary (and not always achievable). For instance, adding a new public interface to an existing API package may introduce an ambiguous package reference into source code containing multiple on-demand type (".*") imports. Similarly, removing a method throws declaration for a checked exception may cause the compiler to detect dead code in a try-catch block. Happily, the kinds of problems that could be introduced into Client source code can always be easily corrected. The notion of API source compatibility is not a requirement. (Note: Problems detected by a Java compiler are therefore not necessarily indicators of any kind of API compatibility that we care about.)"

So the principle is that existing clients should continue to work without being recompiled. In the concrete case that Christian brings up, his plug-ins (and other plug-ins that depend on his) should continue to work, and I don't expect any no link-time or run-time problems. Though it wouldn't hurt to test that to make sure. ;-)

Boris

On Fri, Mar 19, 2010 at 6:25 AM, Markus Keller <markus_keller@xxxxxxxxxx> wrote:
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



_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev