Java 9 (build 9-ea+155, mixed mode) problems


(steve) #1

I have seen a few reports regarding people having problems running Gradle with Java 9, such as here and here etc. However I see nothing in terms of replies, plans and/or discussions of when this is planned to be fixed.

Trust me, I understand the ongoing frustration with early adoption of Java 9. We have been trying to be proactive about this with the Hibernate projects as well. But as far as we understand, Java 9 is finally coming close to freeze and it would be nice to get any additional feedback we might have to the EG ASAP.

We currently see problems with the 155 build[1]. Our last successful CI build using Gradle and Java 9 used the 143 build, if that helps.

Can someone from the Gradle team please comment on the plans to support Java 9? ATM projects like Hibernate are struck in the water in providing early Java 9 feedback because Gradle is holding us back. We’d just like to understand what expectations we should have.

And no, 3.4-rc-3 does not fix the problem :stuck_out_tongue_winking_eye:

[1] https://gist.github.com/sebersole/7f8335ca1ebc7e4c298e7019be684edb


(Stefan Oehme) #2

We currently don’t have capacity to look into these problems, especially since Java 9 proved to be so much of a moving target. We will start working on Java 9 support again in April.

Could you elaborate how exactly this is holding you back? You don’t need to run Gradle on Java 9 in order to compile for Java 9. You can use forked compilation and explicitly set the executable through javaCompile.options.forkOptions.executable = .... It’ll be slower than usual (because we need to fork on every invocation), but it should work.


(steve) #3

Well the important aspect is running test. That something compiles using Java 9 is marginally useful; what is really useful is knowing whether something runs on Java 9 JVM (aka did I sprinkle the right amount of module magic on my jar?).

Conceptually we could do the reverse I guess - launch Gradle with Java 8, specify Java 9 for test executable. But we had a very similar setup for handling the move to Java 8, and it works (far) less than spectacularly; in fact I am not sure it ever really worked. I can certainly try that again, but I really hate (and have a hard time prioritizing) work to work around things that a tool I am using should just do anyway. Its not just the upfront time/cost either; on the back-end there is a cost to undo those hacks…


(Stefan Oehme) #4

That’s the best I can recommend right now, yes.