Detect dependencies through Java 8 Lambdas

[maxbechtold]

I just noticed that the package graph will not highlight dependencies when these are only based on references to other types in Lambda expressions or method references.

So to Usus, a type A does not depend on a type B if A only contains usages like () -> new B() or B::someMethod.

This is probably due to the fact that most of Usus was developed prior to Java 8.
It might not be a show stopper, but still reduces Usus' benefit to me.

[maxbechtold]

I pushed a branch that contains the basic fix - updating the used AST parser. I didn't file a pull request yet as there's the ramification of the required Eclipse version, or rather its bundle org.eclipse.jdt.core

So far the minimum required Eclipse version for Usus was 3.4, but the Java 8 aware AST was only introduced with org.eclipse.jdt.core 3.10.0, included in Eclipse 4.4 (Luna). With 4.7 (Oxygen) available for some time now, it's probably acceptable to drop support for versions prior to 4.4.

Also, I'm hesitant to add a unit test for Java 8 relations, as it would suggest to update the runtime of org.projectusus.core.test to Java 8, while the other projects remain at 1.6.

Any suggestions?

[marcphilipp]

Luna was released in 2014 so I think it would be ok to drop support for prior versions.

[NicoleRauch]

Sounds totally reasonable to me.

Thanks @maxbechtold for bringing this up and for fixing it!

[maxbechtold]

Thanks for your feedback, I'll try and create the pull request soon.

Can you comment on whether or not to update the test project to Java 8?
Since the related tests basically load & parse a .java file from the project, updating the compile level is not strictly necessary. It helps, though, as the files must otherwise be kept from the IDE's attention so as not to lead to compile errors (e.g. outside of Eclipse's build path)

[NicoleRauch]

I would very much like to keep the test .java files under IDE control in order to make sure that they compile.
(I just had a similar case where somebody generated some Java files via a Maven artefact, wrote a test that compared the generation results to some "golden master" Java files, but overlooked the fact that there was a compile error in those golden masters - ouch!)

Having said that, I think it is totally reasonable to update the whole project to Java 8 (prod and test code). But I'm not sure whether / how this step might influence compatibility with Eclipse versions -- do you know about that? It seems that only Eclipse 4.6 actually requires Java 8 as its runtime, but I assume that the actual Usus JAR can be created for Java 6 or so?! (sorry, i did not do any "real" Java development for the past few years, so I forgot about those details...)

[maxbechtold]

I think we're on the same page then.
I can't verify this right away, but it is my understanding that org.projectusus.core.test is a test scope project and not part of any plug-in or feature, thus not part of Usus at runtime. If it is, it might be possible to define compile levels for main and test scope independently.

[NicoleRauch]

I was thinking that while you're at it, you might as well switch everything to Java 8 :-) so that you can make use of the nice language features in Usus as well.

If this doesn't work out for compatibility reasons, then I guess we can have the tests at a different language level than the prod code.

[maxbechtold]

It's actually sufficient to let Eclipse treat the test project (without prod/test distinction) as a Java 8 project. The Tycho/Maven build is not affected, and the required Java runtime stays 1.6.

Still, it's probably about time to move the projects to the recent Java version, which would be 9 (albeit Eclipse support is still to be finally released). However, this is not something I would like to do in a fix contribution. Also, it would probably be a good opportunity to update Tycho and the used libraries (jgrapht, guava etc.) plus apply some formatting clean up (use of the diamond operator, replace anonymous classes with lambdas etc.)

[maxbechtold]

@marcphilipp and I agreed on me releasing the next Usus version. I created the release notes, feel free to review Release_Notes_0.8.0.md.
As to the version number - since we no longer support the old 3.x Eclipse versions, I find a change in the minor digit justified (it's also easy to remember this as the version with Java 8 support). Any objections?

Remaining tasks:

• tag the release
• build it
• prepare next release
• update the version requirements on the Eclipse Marketplace page - do we need help from @stefanschuerle with this?

[marcphilipp]

update the version requirements on the Eclipse Marketplace page - do we need help from @stefanschuerle with this?

I can also edit the marketplace entry. Moreover, I can add you to the editors if you give me your Eclipse account (or create an account if you don't have one already).

[NicoleRauch]

Sounds excellent! Thank you :-)

[maxbechtold]

Most of it is done, except spreading the word and updating the Eclipse Marketplace (I'm https://www.eclipse.org/user/mbechtoldnhp)
I installed the new version, after a quick test it seems to work properly.

[marcphilipp]

You should now be able to edit the Eclipse Marketplace entry.

[maxbechtold]

Thanks, and I did.