I have a project that has the sourceCompatability and targetCompatability set and am building with JDK 8. This works from the command line, but when I import it into Eclipse using Buildship 2.0 I get the following error
Description Resource Path Location Type
Unbound classpath container: 'JRE System Library [JavaSE-1.5]' in project 'missing-jdt' missing-jdt Build path Build Path Problem
Here is a simple configuration that reproduces the problem
apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = 1.5
targetCompatibility = 1.5
I realize that I can override the runtime name with
javaRuntimeName = "J2SE-1.8"
However, I do not know what the name will be for other users. A workaround is to require the users to have a Java Runtime with a specific name, but this does not seem ideal.
Does anyone have any suggestions on what I can do to make this easy for the users (i.e. work with any JDK > the compatibility)?
Eclipse comes with default execution environments for all Java versions and automatically picks a compatible JRE, so this should just work. I wonder why this is not working in your case. What Eclipse version are you using?
Oh, I see what’s going on here: Gradle is not using the correct naming convention for Java 5. It should be
J2SE-1.5 as the javaRuntimeName. Eclipse changed the convention to
JavaSE- starting with Java 6. I guess we dropped the special handling when we dropped Java 5 support.
Thanks this gives me a reasonable workaround for the problem!
Specifying the following resolves the issue for me
javaRuntimeName = "J2SE-1.5"
Perhaps I misunderstood, but my understanding was that as long as I was compiling with JDK 8 a source/target of 1.5 was still supported (the JDK supports it so why wouldn’t Gradle?). If this is not the case, it would be nice if Gradle output some warnings when specifying source/target of 1.5.
You’re right that does still work, we just don’t support the actual Java 5 compiler anymore. It might be that the logic in Gradle core was never correct, Buildship used to use its own. @donat that should be easy to fix, should we do that for 3.4?
I think so. I had a quick peek at the source code and it seems simple to fix.
Thanks for the quick workaround and scheduling a fix!