Skip to main content


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 Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
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 WebsterFriend
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 KellerFriend
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 Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
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:Horizontal scrolling in table with cell editors?
Next Topic:[databinding] ObservableTreeContentProvider and WritableList used together?
Goto Forum:
  


Current Time: Fri Mar 29 01:26:40 GMT 2024

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

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

Back to the top