NullPointerException preventing Groovy compilation #616
Comments
|
Can you try running with JDK8 just to see if it is the module system stuff getting in the way? See #582 |
|
Sorry - I should have been clearer. Eclipse is running under JDK8 (64-bit build 152 - java.runtime.version=1.8.0_152-b16). I am compiling with JDK10 (and have no option otherwise - my current task is to get our build upgraded to JDK10). Also just realised that more of the stack trace could be useful since it's in the JDK patch - put the full trace there. |
|
Thanks for the clarification. The modulepath is unsupported at the moment. I realize this is a big gap in Java 9+ support and have been working on it for 3.0.0. Batch and Maven compilation use a different class loading scheme and should be compatible if the target JRE is used for compilation. |
|
I don't understand why you closed this, or how your last comment addresses this issue. I don't see anything that indicates this is related to modulepath. Would my proposed null check be insufficient as a fix, and if so why? As far as I can tell there is no workaround I can use to avoid this issue. Our primary build is Gradle (these are Gradle projects imported) - Eclipse + Groovy-Eclipse is for ease of development. If I can't get this working then I'm going to have to abandon Eclipse (which would be very painful - changing IDEs is no fun). |
|
By closing I am not saying that everything is fine. I am presently testing Java 9+ support -- there are definitely known issues. I understand that you have build issues. If you do not think this is related to the modulepath, please supply some additional details. I'll need to know what your project looks like (.classpath, .project, .settings, build.gradle, etc. -- best to supply a small zip or a github link) I can be reached on Slack if you wish to discuss more quickly/privately. |
|
Actually, I think I understand. With the following .project and .classpath, are you saying that JavaSE-10 having If so, do you have any kind of timeframe for when JDK9+ might be supported? Unfortunately, this is a complete showstopper for me ... Note: I'm using Gradle STS, configured to not export Gradle dependencies ... I've obviously trimmed .classpath below. .project .classpath |
|
Yes, having a JavaSE-9+ (module=true attribute in classpath) means the rt.jar is replaced by the *.jmod stuff. The GroovyClassLoader/URLClassLoader does not load from these. You could set your JRE container to JavaSE-8 and it would still run on Java 9+. Groovy 2.4 is actually built with Java 6 support. As for modulepath support, I could restore the ability to run Eclipse with the JDK version you plan to target and so the classes from the JDK would be loaded by Eclipse classloaders. The original issue there is you could be using classes from your Eclipse runtime that would not be available when your project is tested or deployed. |
|
Unfortunately I have to use JavaSE-10 as that's the point of the work I'm doing at the moment - getting our code building with the JDK10 compiler. At least as a short-term option using if using the Eclipse classloaders would give JDK10 support (by running Eclipse under JDK10) then I think that would be preferable to the current situation. Our canonical build is via the command line (and Jenkins) - accidentally using classes that aren't in our gradle dependencies would be quickly caught. |
for Java 9+ until proper modulepath support can be implemented
|
Building now: https://build.spring.io/browse/GRECLIPSE-E47M-216 |
|
There are 2 new test failures - is this a problem, or can I test with it? I updated to the latest e4.7 snapshot and changed my eclipse.ini to use JDK10: 3.0.0.xx-201807021459-e47 but still getting the NullPointerException, so either that didn't fix it, or I didn't get the version with the fix due to the test failures. |
|
Is it the exact same exception? Are there any errors reported in your Error Log view? |
|
While I was doing this a new version came through - 3.0.0.xx-201807022141-e47. Still getting a NullPointerException, but there is one difference - line number change in the stack trace: org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:175) (previously was line 180). Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". eclipse.buildId=4.7.3.M20180330-0640 java.lang.NullPointerException |
|
What it's trying to do is resolve the annotations for some method. The annotation attribute is trying to be resolved against the imports. Way down in Scope.getTypeOrPackage(Scope.java:3311) it is checking against the star imports and getting null for the binding (package or type). Last line here is the top of the stack trace: // check on demand imports
if (imports != null) {
boolean foundInImport = false;
ReferenceBinding type = null;
for (int i = 0, length = imports.length; i < length; i++) {
ImportBinding someImport = imports[i];
if (someImport.onDemand) {
Binding resolvedImport = someImport.resolvedImport;
ReferenceBinding temp = null;
if (resolvedImport instanceof PackageBinding) {
temp = findType(name, (PackageBinding) resolvedImport, currentPackage);
} else if (someImport.isStatic()) {
// Imports are always resolved in the CU Scope (bug 520874)
temp = compilationUnitScope().findMemberType(name, (ReferenceBinding) resolvedImport); // static imports are allowed to see inherited member types
if (temp != null && !temp.isStatic())
temp = null;
} else {
temp = compilationUnitScope().findDirectMemberType(name, (ReferenceBinding) resolvedImport);I wish I knew what method is being resolved and what annotation is not being resolved properly. |
|
I'm wondering if maybe it would be worthwhile doing a temporary variation of my fix - catch the Hopefully it would either log something related to my source code, or to the groovy-eclipse source - either would be useful info. If it's related to my source it might help be produce a minimal case that you could use to replicate. |
|
Can you search your code for any non-static, on-demand imports like As for logging, the problem is upstream somewhere; a type binding is not found. Have you checked your Error Log view for additional errors? |
|
I am rolling back the recent change that I think is causing a number of NPEs reported in the last few days. Build should be available in a few hours. |
|
No other errors at all in the error log. I'm not going to upgrade to any new version yet as I want to test something out to see if it's the cause (see below). I've changed some package and class names below to be generic (actual code belongs to my employer). I had: but no non-static in groovy code. Changing those to be normal imports (and qualifying the constants in the code) didn't fix the error. However, additional errors occur afterwards (both with and without the import changes) and they happen to point directly at a related trait - test.utils.CsvUtils (I suspect that might be coincidental though - they are used in the same test code). The trait is defined like: TestUtils.groovy: and then used by test classes like: in order to mix-in the behaviour to classes that couldn't directly extend it. I might be able to refactor the code to avoid using the trait. This isn't the only trait I have, but I think it's the only one with static methods, so I'll see if that refactoring fixes the issue - I'll let you know. Exception: |
|
So I've removed all traits from the codebase, replacing with classes where feasible and java interfaces with default methods. Still getting a NullPointerException in the same location, but quite a different stack trace. So I think we can eliminate traits as being the cause of this. |
|
The NPE begins upstream here in protected ImportBinding[] getDefaultImports() {
if (defaultGroovyImports != null) return defaultGroovyImports;
List<ImportBinding> importBindings = new ArrayList<>();
Collections.addAll(importBindings, super.getDefaultImports()); // picks up 'java.lang'
// augment with the Groovy on-demand imports
importBindings.add(new ImportBinding(javaIo, true, environment.createPackage(javaIo), null));
importBindings.add(new ImportBinding(javaNet, true, environment.createPackage(javaNet), null));
importBindings.add(new ImportBinding(javaUtil, true, environment.createPackage(javaUtil), null)); |
Eclipse Oxygen and Photon, JDK10 (for compilation), Groovy-Eclipse 3.0.0 (snapshot). This occurs with the latest snapshot 3.0.0.xx-201806281902-e47 (for Oxygen).
This error prevents compilation of Groovy code entirely.
On Eclipse Oxygen, the error is:
Digging into the code -
org.eclipse.jdt.internal.compiler.lookup.Scope.java:it looks like
enclosingTypemust be null. I would guess the fix is:but I have no idea why
enclosingTypewould be null, so there may be a more complex fix needed.Unfortunately I'm having trouble building Groovy-Eclipse in my environment, so I can't test this fix at the moment.
The text was updated successfully, but these errors were encountered: