[handly-dev] A milestone build of Handly 0.7

[Vladimir Piskarev <pisv@xxxxx>]

Greetings handly-dev,

I'm pleased to announce the availability of a milestone build that represents an attempt at API freeze towards the upcoming Handly 0.7 release. Early adopters are most welcome to check out and comment on this build. I'll be happy to answer any questions you might have.

Update site:
http://download.eclipse.org/handly/drops/0.7M1/repository

Archived repository:
http://www.eclipse.org/downloads/download.php?file=/handly/drops/0.7M1/handly-repository-incubation-0.7M1.zip

Issues targeted by the 0.7 release:
https://projects.eclipse.org/projects/technology.handly/releases/0.7/bugs

Almost all of the issues are concerned with Core API quality. A major driver for the 0.7 development has been an experiment in making a local fork of JDT (Neon) run on Handly; in other words, trying to adopt Handly within the context of a large-scale existing model implementation. In a large part, this experiment has been a success; we have incorporated a 0.7 prototype in an internal fork of JDT with all of the nearly 8000 JUnit tests for the JDT Java model running successfully. (We have yet to adopt the 0.7M1 in the fork before we're ready to publish the results.) None of the public JDT APIs were affected by this change in any way. Notably, most of the internal JDT APIs were also kept intact. This did require (relatively mild) breaking changes in Handly Core API here and there, though.

Let me bring your attention to a couple of the most affecting changes:

* A number of "trait-like" *ImplSupport interfaces have been introduced (Bug 515667) to provide skeletal implementations of *Impl interfaces for elements in a way that allows implementors to "mix in" *ImplSupport interfaces directly or extend classes in the Element hierarchy (which now implement corresponding *ImplSupport interfaces) as they see fit. Basically, we have extracted methods from the Element class hierarchy to default methods in *ImplSupport interfaces to enable a form of "multiple inheritance of behavior" and overcome limitations imposed by single inheritance. Since interfaces cannot have protected members, members in the Element hierarchy that were previously protected have become public. Although this does not break binary compatibility, this change is not source compatible with respect to protected method overrides. In other words, existing element classes will need to change the access modifier for methods like hValidateExistence and hBuildStructure from "protected" to "public".

https://bugs.eclipse.org/bugs/show_bug.cgi?id=515667

* SourceFile#hBuildSourceStructure method has been introduced (Bug 515246) in place of the current #hBuildStructure method to fix an earlier API mistake. Obviously, this is a breaking change: existing SourceFile's subclasses will need to implement hBuildSourceStructure instead of hBuildStructure. The method implementation itself doesn't need to change though.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=515246

I'll come up with a more detailed N&N list and a migration guide before the 0.7 release date (June 28, 2017). In the meantime, please let me know if there are any questions or comments.

Thanks,
Vladimir