[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Suggestion to restructure UIEvents to increase clarity and performance (Evolving Java-based APIs)
|
Brian de Alwis <briandealwis@xxxxxxxxx> 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