On Buildship 1.0.9.v20160211-1429, default project settings for Java Compiler (JDK) are overwritten.
In gradle.prefs I had a null value for connection_java_home and the project settings were being used. This worked fine until the latest Buildship update. Now, no matter what I set in the project, it gets overwritten.
I wrote about this here: Stop Eclipse updates on classpath and settings.
This is a known issue and will be fixed with Buildship 1.0.10
See discussion at the end of https://bugs.eclipse.org/bugs/show_bug.cgi?id=472996
This issue has been fixed in Buildship and will be released next week. If you want to evaluate you can install the latest milestone build from the following update site: http://download.eclipse.org/buildship/updates/e45/milestones/1.0/1.0.10.v20160309-1150-m
We appreciate any feedback.
Iâm testing version 1.0.10. Now, when I refresh the project:
gradle.prefs is removedorg.eclipse.buildship.core.prefs this lines were added:build.commands=org.eclipse.jdt.core.javabuilder connection.arguments= connection.gradle.distribution=GRADLE_DISTRIBUTION(WRAPPER) connection.gradle.user.home=null connection.java.home=null connection.jvm.arguments= connection.project.dir= natures=org.eclipse.jdt.core.javanature project.path=\:
.classpath this line is modified (StandardVMType added):<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
This last change introduced many errors: âAccess restriction: ⌠is not API (restriction on required library ⌠rt.jar)â. I solved this by selecting the JDK, instead of using the âExecution environmentâ.
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6.0_43"/>
Is this the expected behaviour?
Update: when I refresh the project, this last change is undone. That is, Gradle changes jdk1.6.0_43 back to JavaSE-1.6.
@donat @st_oehme
even using connection.java.home=C:\\Program Files\\Java\\jdk1.6.0_43 on org.eclipse.buildship.core.prefs sets the âExecution environmentâ JavaSE-1.6.
So, there is no way of setting an alternate JRE/JDK.
Update: using gradle.properties with
org.gradle.java.home=C:\\Program Files\\Java\\jdk1.6.0_43
is not working either.
We are currently making use of execution environments only. If you want your special VM to be used, set it as the default VM for that execution environment.
There is also an enhancement request that will allow selecting a JVM by name. This has somewhat lower priority though, as it is not very portable. It would mean that every developer on the team would have to set up Eclipse with precisely the right VM names.
Also there is no need to tinker with the java.home setting. It was never meant to specify the JDK to use for the Eclipse project. Itâs just the JDK that the Gradle build itself will run on.
Changing the default VM for the Execution environment does not solve the âAccess restrictionâ error messages from eclipse. So, using that is not exactly the same as setting the Alternate JRE.
Anyway, I changed the few references that I had to sun.* to solve that and Iâm using what Gradle sets (Execution environment > JavaSE-1.6).
Is there any reason to only support execution environments? By doing so, using gradle for creating eclipse projects using JavaFX is impossible since the execution enviroment sets some access rules prohibiting the use of the JavaFX bundled in the ext folder of the Java 8 installation. Manually switching in eclipse from execution enviroment to workspace default JRE solves this issue but itâs there again after regenerating the eclipse project from gradle.
The reason is that exposing the required information via the Tooling API takes a significant amount of time, and so far we havenât seen a reason to prioritise this feature. The select a JVM by name feature would solve your problems, is that correct?
Yes, I think a selection by name would be useful in my case.
(see also Setting execution environments instead of JRE prohibits use of JavaFX bundled with Java8 where I described the problem as an own topic).
I am having issues with the âAccess restrictionâ error messages in eclipse as well and I canât seem to fix them when using buildship in eclipse. Could you share how you got around this with buildship/gradle?
With Buildship 1.0.18 and Gradle 3.0 you can set the eclipse.jdt.javaRuntimeName to a JVM whose access restrictions are more open.
Sorry that I am not reading between the lines here⌠but i still donât understand?
What jvm would be less restrictive? I am using the latest oracle 1.8 jvm. (jre 1.8 101). I have updated to both gradle 3.0 and Buildship 1.0.18.
I have set my subprojects to use:
eclipse {
jdt {
javaRuntimeName = "JavaSE-1.8"
}
}
sourceCompatibility = 1.8What you pasted is the default, sourceCompatibility = 1.8 would be enough in that case.
The problem is that in Eclipse JREs are configured to forbid access to Sun-internal APIs by default. âJavaSE-1.8â is a predefined execution environment that you cannot change in Eclipse. Instead, youâll have to create your own JRE and give it a name. Then you can use that name in javaRuntimeName.
Ok, i was just hoping for a non-manual solution, but this works OK.
You can also shut off those warnings in Eclipseâs compiler settings if you want. But they are generally valid. If you access those internal APIs, your code is not guaranteed to run on all JREs.
Understood, found a pretty good explanation here as well: http://stackoverflow.com/questions/22812488/using-javafx-in-jre-8
We are using javafx for an internal testing tool gui, so we are ok with it not running on all JVMs.
With the gradle âeclipseâ plugin we got around this with this by doing something like below, but this breaks buildship by removing the jvm somehowâŚ
eclipse {
classpath {
file {
whenMerged { classpath ->
classpath.entries.findAll{entry -> entry.kind == 'con'}.each{
def componentName = it.path
withXml {
def node = it.asNode()
node.appendNode('classpathentry', [kind: 'con', path: componentName]).appendNode('accessrules').appendNode('accessrule', [kind: 'accessible', pattern: 'javafx/**'])
}
}
classpath.entries -= classpath.entries.findAll{entry -> entry.kind == 'con' }
}
}
}
}
Please have a look at the Buildship 1.0.18 release notes. You can do this customization much more straightforward, without XML mangling and in a way that Buildship will understand 
Exactly what i was looking for!! Here is the slightly modified snippet from the release notes as it applies to javafx.
Really great documentation⌠thanks for such a great product!!
import org.gradle.plugins.ide.eclipse.model.AccessRule
apply plugin: 'java'
apply plugin: 'eclipse'
eclipse {
classpath {
file {
whenMerged {
def jre = entries.find { it.path.contains 'org.eclipse.jdt.launching.JRE_CONTAINER' }
jre.accessRules.add(new AccessRule('0', 'javafx/**'))
}
}
}
}