Skip to main content

[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 ?

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

You should make the methods public in the overriding classes. That will be source and binary compatible with both 3.5 and 3.6.


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


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:

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

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



Paul Webster
Hi floor.  Make me a sammich! - GIR
platform-ui-dev mailing list

Back to the top