API Breakage(-ish) in 3.6 M6 ? [message #521832] |
Thu, 18 March 2010 15:30 |
|
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
|
|
|
|
|
Re: API Breakage(-ish) in 3.6 M6 ? [message #522067 is a reply to message #521928] |
Fri, 19 March 2010 19:18 |
|
Thanks, Markus,
That seems to answer my question. I suppose that the TitleAreaDialog
scenario is analogous the the example in the JLS if one imagines that
TitleAreaDialog had previously declared the getMessage() method as
protected.
In looking further into the code that I need to adjust, I see that my
existing getMessage() methods actually are not true to their name: they
only provide a portion of a message pattern so that, in fact, users of
the TitleAreaDialog::getMessage() API would get a result that is less
than the whole message promised by that API. IOW, my code is already in
violation of the new-in-3.6 API contract. Oh, well. I'll just have to
do a bit more of refactoring to use appropriate names.
Thanks again,
Christian
On 19/03/10 06:46 AM, Markus Keller wrote:
> My answer from platform-ui-dev:
>
> 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/binary Comp.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
|
|
|
Powered by
FUDForum. Page generated in 0.02566 seconds