Skip to main content

[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


Back to the top