[
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.
"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 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