If we do this in 4.2 we're OK since none of the API and been cast in
concrete yet (all 4.1 API is considered provisional). If we agree that
this is something that makes the API easier to consume then now is the
time to do it, after 4.2 ships it'll be too late. We should of course also
try to mitigate the impact of folks already using the current mechanism
through blogs...
I'll also try to directly contact Simon Chemouil, the other brave soul
that built a commercial offering on Eclipse 4.1...;-), just to make sure
he understands the change and can synch up once we're done.
My personal opinion is that this sounds like a good thing to me. A few
quick searches shows that most folks use the specific version of the
buildTopic call which specifies the topic all the way down to the
attribute level. In a few cases we use the general one; this is mostly
used for handling UILabel so that one listener can be used to keep the
Label, Icon and Tooltip up-to-date (the other one isn't used at all).
I think that
eventBroker.subscribe(UIEvents.Dirtyable.DIRTY,
dirtyUpdater);
eventBroker.subscribe(UIEvents.UILabel.ALL, itemUpdater);
scan better than
eventBroker.subscribe(UIEvents.buildTopic
(UIEvents.Dirtyable.TOPIC,
UIEvents.Dirtyable.DIRTY), dirtyUpdater);
eventBroker.subscribe(UIEvents.buildTopic
(UIEvents.UILabel.TOPIC),
itemUpdater);
(The use of the new 'ALL' constant rather than the existing 'TOPIC' is my
initial lame attempt to make its name more reflective of its intent...;-).
Dean has already done the initial version of the experiment, changing the
generator and the builldTopic implementations but there appear to be a few
cases where we're building the topic string directly which we'd have to
track down. Other than that the refactoring to get rid of the current uses
of buildTopic is straightforward.
Whether or not we leave deprecated versions of buildTopic in the UIEvents
class would depend on how widely they're used outside of our
implementation. For my money I'd deprecate them in M4 (to give Simon et al
time to catch up) and then *remove* them in M5 (which would still give us
time to put them back if there's a heavy push from the community).
Eric
From:
Markus Keller <[email protected]>
To:
E4 Project developer mailing list <[email protected]>
Date:
11/10/2011 12:17 PM
Subject:
Re: [e4-dev] Suggestion to restructure UIEvents to increase clarity and
performance (Evolving Java-based APIs)
Sent by:
[email protected]
Brian de Alwis <[email protected]> wrote on 2011-11-10 17:39:44:
> On 10-Nov-2011, at 10:55 AM, Dean Roberts wrote:
> > Do we have to be compatible with previously compiled .class files
> ... I'm assuming the answer is going to be yes here.
>
> So it really hinges on: are we guaranteed that all existing compiled
> classes that referenced the previous version of
> UIEvents.UIElement.VISIBLE would have had the string inlined?
>
> I believe the Java compilers inline static final string references.
> But I don't know if they *have* to, nor as to whether there are any
> that don't. Anybody know the applicable part of the JLS?
Every Eclipse committer should read
http://wiki.eclipse.org/Evolving_Java-based_APIs every once in a while.
That document tells the whole story about API compatibility in an
easy-to-digest form.
This concrete case is described here:
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_classes_-_API_fields
> Change value of API field If field is compile-time constant Breaks
compatibility (2)
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.9
has the full story.
Note that we only guarantee compatibility for APIs that have already been
released. If this constant has only been added in the 4.2 cycle, then you
can still change the value.
HTH,
Markus
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
