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?

[nedtwigg]

There is a PR by gabor bernat which builds and runs under Java 7. If you check it out and build it, and I believe it will work.

I haven't merged it because there are a few places where it replaces pure functions (which are hard to use incorrectly) with new kinds of objects that have init() methods which have to be managed correctly and have the right method called at the right time. I'm happy to maintain a java7 port, but I'm not going to maintain a java7 rewrite.

Moving forward would be fairly straight forward. If you check out the java7 branch, there is an incomplete port in the functional style. You'd basically just have to replace the method references which don't compile with the work that gabor did in his PR.

So the pieces are all there. But projects are adopting java 8 waaaay faster than they adopted 6 or 7, so I think you're better off spending the time figuring out how to upgrade your build server to Java 8 ;-) Eclipse Neon comes out in two months, and it requires Java 8, so right off the bat a Java 7 port is going to be missing bugfixes that the Java 8 port can do.

[jtnelson]

Thanks for the update. You're right, might as well upgrade to Java 8 :)

Sent from my iPhone

On Tue, Apr 12, 2016 at 7:33 AM -0700, "Ned Twigg" notifications@github.com wrote:

There is a PR by gabor bernat which builds and runs under Java 7. If you check it out and build it, and I believe it will work.

I haven't merged it because there are a few places where it replaces pure functions (which are hard to use incorrectly) with new kinds of objects that have init() methods which have to be managed correctly and have the right method called at the right time. I'm happy to maintain a java7 port, but I'm not going to maintain a java7 rewrite.

Moving forward would be fairly straight forward. If you check out the java7 branch, there is an incomplete port in the functional style. You'd basically just have to replace the method references which don't compile with the work that gabor did in his PR.

So the pieces are all there. But projects are adopting java 8 waaaay faster than they adopted 6 or 7, so I think you're better off spending the time figuring out how to upgrade your build server to Java 8 ;-) Eclipse Neon comes out in two months, and it requires Java 8, so right off the bat a Java 7 port is going to be missing bugfixes that the Java 8 port can do.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[nedtwigg]

Just updated to Eclipse Neon, which requires Java 8 and has a bunch of bugfixes relative to previous versions. Very hard to justify a Java 7 version at this point.