Some Projects don't work with Java 11 based Java plugin

[tsmaeder]

We've recently updated the Che Java tooling to Java 11. It seems of our featured examples do not work with this: https://github.com/spring-guides/gs-rest-service
The project contains setup for both maven and gradle. In this case, jdt.ls sets the project up as a gradle project. However, the project uses gradle 4.6. jdt.ls picks up that tooling, but that craps out because gradle 4.6 does not support running on Java 11.
Need to have a discussion on what the best way forward is.

[ibuziuk]

the issue is reproducible via devfile for spring-rest-guide - https://github.com/ibuziuk/my-che-devfiles/tree/master/spring-rest-guide#the-gradle-version-used-in-that-project-does-not-work-on-java-11

One of the ideas was to exclude gradle via Java.import.gradle.enabled:false property.
@skabashnyuk @sleshchenko any ideas how this can be configured in the devfile?

[nickboldt]

The gs-rest-service sample project sort of works with the Che 7 RC1 Gradle 5.2.1 / JDK 11 stack image:

https://user-images.githubusercontent.com/227597/59536122-d894b480-8ec0-11e9-9e98-078c0c03a39d.png

However, the lang server (?) or something under the covers is still trying to download gradle 4.6:

And the console-java-simple project is also confused about JDK 11 (as seen above), but it does work:

[tsmaeder]

@nickboldt this is really about the fact that the Java language support plugin is not working.

[nickboldt]

Will Java lang support work in time for CRW 2.0? Because if not, I'd suggest reverting whatever you changed to "support" JDK 11. Let's go back to JDK 8, where things worked. :D

I mean, I may not be the target audience for Che and CRW, but I think Java 8 support is still pretty important for enterprise. WDYT @slemeur ? This feels like a P1/SEV1/blocker for CRW 2.0 to me.

[tsmaeder]

Ok, after some discussion we're going with a Che plugin per Java version. However, there are a couple of open questions:

1. Later Java versions (than 8, that I know) don't have official Alpine images. Is there a preference for some other base? Is having a community image ok to use?
2. For which versions should we provide a plugin version? Does it make sense to provide 8, 9, 10, 11, 12 or just 8 and latest (12)
3. Does jdt.ls even support Java 12 yet?
4. Does the "java" folder as default even make sense? The only case where it would make sense is for compatilibity with existing dev-files, but I would say we don't care about that because we're not GA yet.

@l0rd @fbricon @svor @benoitf

[benoitf]

now alpine is supported by openjdk project https://hub.docker.com/_/openjdk 13-alpine (but this is for the future)

[slemeur]

Can we consider this issue closed since eclipse-che/che-plugin-registry#181 has been merged?

cc @svor and @tsmaeder

[tsmaeder]

Yes we can!