Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » JFace » API Breakage(-ish) in 3.6 M6 ?
API Breakage(-ish) in 3.6 M6 ? [message #521832] Thu, 18 March 2010 15:30 Go to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 794
Registered: July 2009
Senior Member
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 #521856 is a reply to message #521832] Thu, 18 March 2010 22:34 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Hi Christian,

I've posted your message to the platform-ui-dev mailing list,
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

We'll have to look at this in M7

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm


Re: API Breakage(-ish) in 3.6 M6 ? [message #521928 is a reply to message #521832] Fri, 19 March 2010 05:56 Go to previous messageGo to next message
Markus Keller
Messages: 294
Registered: July 2009
Senior Member
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
Re: API Breakage(-ish) in 3.6 M6 ? [message #522067 is a reply to message #521928] Fri, 19 March 2010 19:18 Go to previous message
Christian W. Damus is currently offline Christian W. Damus
Messages: 794
Registered: July 2009
Senior Member
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
Previous Topic:Rendering HTML Table in Eclipse FormText Control
Next Topic:FilteredTree - get visible items on filter
Goto Forum:
  


Current Time: Tue Sep 30 17:56:37 GMT 2014

Powered by FUDForum. Page generated in 0.05090 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software