Support Gradle running on Java 7

[gaborbernat]

can we add support for this please?

[nedtwigg]

Just to be clear, spotless can already format Java 7 (or earlier) code, but it requires that gradle is being run by Java 8+.

To allow spotless to run on Java 7, the following steps would need to be taken:

• Remove the Durian dependency. It's only used in a few places, this is an easy fix.
• Convert all lambdas to anonymous inner classes. Your IDE can do this for you.
• Misc. mopping up.

Spotless has a lot of lambdas, so it will decrease readability a fair bit. But if you can't use it, it doesn't matter if it's easy to read. If you make the change, I'll be happy to merge.

[nedtwigg]

Something else to consider: Eclipse Neon (coming out in June 2016) will require Java 8. So in 9 months, the latest formatter with the latest bugfixes is going to require Java 8 anyway.

If anyone pulls off the Java 8 -> 7 conversion, I'd still be happy to merge it and release a version that works with Java 7. But I'll definitely be reverting those changes in a year to make sure we always have the latest and greatest formatter available.

[gaborbernat]

I see your point. In the meantime I think it would be beneficial to have a version Java 7 conversion.

[nedtwigg]

If you've got a Java 7 constraint, and it's easier for you to backport Spotless to Java 7 than it is to upgrade your constraint to Java 8, go for it! I'll merge and release, and maintain it as Java 7 for the next 9 months until Eclipse Neon is available.

[nedtwigg]

Don't forget that the gradle java plugin has these properties: sourceCompatibility, targetCompatibility. You can upgrade the Java that's running your Gradle without upgrading your actual project.

[nedtwigg]

I've uploaded a java7 branch. At the moment, it has just two commits:

Set compiler version to 1.7 and added the missing java functional interfaces
Remove the durian dependency and copy-paste its contents into spotless

The nice thing about this approach is that if people make improvements to master, it will be very easy to merge these improvements into the java7 branch. In order to make this work, you'd have to go through and replace all the lambdas and method references with anonymous inner classes.

I'm not convinced that finishing this is easier than upgrading a constraint, but if long-term Java 7 support is important to you, feel free to continue from here.

[gaborbernat]

I feel like changing the lambdas to anonymous inner functions would diverge the two project just as much as the canonical java implementation. :(

[nedtwigg]

Changing the lambdas to anonymous inner functions doesn't change the imports, and it doesn't change the functions you must supply to build a new plugin. This preserves the API completely.

[nedtwigg]

Just a thought. If this Java 7 port happens successfully, we could follow a similar path to release a Java 6 version, if anyone has that requirement. Java 7 limits us to Mars, and Java 6 limits us to Kepler, but Kepler's formatter is still pretty darn good.

By far the hardest part of this whole project is the Java 8 -> Java 7 lambda and method reference conversion, but if that is accomplished, adding 6 would be relatively easy. If Java 7 is accomplished, I'll create a separate issue for Java 6 outlining the process, so that if anyone needs it they can follow the steps.

[jtnelson]

Is this still happening?