Re: [platform-ui-dev] API Breakage(-ish) in 3.6 M6 ?

[Markus Keller <markus_keller@xxxxxxxxxx>]

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