Community
Participate
Working Groups
I tried to check out a big multi-module Maven/Java project that works well in previous versions of Eclipse, using Eclipse 2021-06 and it failed with an error: Steps to reproduce: 1. Install 2021-06 from tarball 2. git clone Apache Accumulo repo (https://github.com/apache/accumulo) and check out latest commit (was: 89b411c391675cb3f1faed83f2dd4451b2ac6d12) outside of Eclipse 3. Use Eclipse GUI to import existing Maven project 4. Navigate to local directory where Accumulo was cloned 5. Click Finish and wait for project to import/build 6. Accept any licenses for popups for M2E extensions This works perfectly in 2021-03, but in 2021-06, it results in a build failure in the "Java Builder", with the message: Cannot read the array length because "this.fields" is null This error message makes no sense, because the error doesn't appear to have anything to do with code in Accumulo. I'm not sure how to debug this further. This is 100% reproducible on Fedora 34, x86_64, using OpenJDK 11 from the Fedora repos, all software up-to-date, and using eclipse-java-2021-06-R-linux-gtk-x86_64.tar.gz downloaded from eclipse.org (SHA-512: 4047a3b89d577689ad5e78959d85843638d04145af4c24173d0567cbf7642d2e5faf4d919b8457203fedd68827b6ad3ddacfe1eba6cc997755b0ab5e05bd7179) Because of this error, 2021-06 is completely unusable for me, and I had to downgrade back to 2021-03.
Created attachment 286670 [details] screenshot-of-java-builder-error
I switched back to 2021-03, and everything worked fine, then I upgraded all components *except* the one listed as: Eclipse Java Development Tools 3.18.800.v20210611-1600 org.eclipse.jdt.feature.group Everything still worked as expected. Then, I upgraded that final component, and it broke. So, it's definitely something in that JDT feature group.
May not be related, but I'm seeing the same error with things like Hover Text, and the Type Hierarchy view. Here's the error (with stack trace) on the Type Hierarchy view. java.lang.NullPointerException: Cannot read the array length because "this.fields" is null at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.declarationOf(TypeDeclaration.java:622) at org.eclipse.jdt.internal.compiler.lookup.RecordComponentBinding.getAnnotationTagBits(RecordComponentBinding.java:92) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor(SourceTypeBinding.java:1401) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.components(SourceTypeBinding.java:1330) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.methods(SourceTypeBinding.java:2189) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.getExactConstructor(SourceTypeBinding.java:1642) at org.eclipse.jdt.internal.compiler.lookup.Scope.getConstructor0(Scope.java:2465) at org.eclipse.jdt.internal.compiler.lookup.Scope.getConstructor(Scope.java:2446) at org.eclipse.jdt.internal.compiler.ast.Statement.findConstructorBinding(Statement.java:588) at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.resolveType(AllocationExpression.java:491) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:794) at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:1113) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:131) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolveIfStatement(IfStatement.java:291) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:317) at org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:144) at org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:1209) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:661) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:362) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:570) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1512) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1637) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:667) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:872) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProject(IndexBasedHierarchyBuilder.java:266) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(IndexBasedHierarchyBuilder.java:377) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:167) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:323) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1319) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:740) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:806) at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:950) at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:907) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.createTypeHierarchy(TypeHierarchyLifeCycle.java:295) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh(TypeHierarchyLifeCycle.java:325) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefreshBackground(TypeHierarchyLifeCycle.java:272) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle$1.run(TypeHierarchyLifeCycle.java:225) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
*** This bug has been marked as a duplicate of bug 574257 ***
This bug was incorrectly marked as a duplicate of bug 574257. It is not a duplicate of that bug, because this one still occurs, even after using the latest nightly builds as of July 25 (https://download.eclipse.org/eclipse/updates/4.21-I-builds/I20210725-1800/)
(In reply to Christopher Tubbs from comment #5) > This bug was incorrectly marked as a duplicate of bug 574257. It is not a > duplicate of that bug, because this one still occurs, even after using the > latest nightly builds as of July 25 > (https://download.eclipse.org/eclipse/updates/4.21-I-builds/I20210725-1800/) Please provide stack trace of the error with latest SDK build.
Created attachment 286833 [details] Error log file after 2021-07-25 nightly I've exported and attached the error log containing the stack trace for this, after updating to the July 25 nightly build.
(In reply to Christopher Tubbs from comment #7) > Created attachment 286833 [details] > Error log file after 2021-07-25 nightly > > I've exported and attached the error log containing the stack trace for > this, after updating to the July 25 nightly build. !SESSION 2021-07-26 13:49:51.587 ----------------------------------------------- eclipse.buildId=4.20.0.I20210611-1600 That is definitely *not* Juli 25 nightly build.
(In reply to Christopher Tubbs from comment #7) > Created attachment 286833 [details] > Error log file after 2021-07-25 nightly > > I've exported and attached the error log containing the stack trace for > this, after updating to the July 25 nightly build. The logs from this old 4.20 build show bug 574468 stack. So if the same stack is produced with latest 4.21 build, this issue is a duplicate of bug 574468 (or vice versa). If that is the case: could you try to reduce the problem you see to a simple example that uses only SDK (no maven, gradle, whatever else 3rd party library), so it could be easier to analyze?
(In reply to Andrey Loskutov from comment #8) > (In reply to Christopher Tubbs from comment #7) > > Created attachment 286833 [details] > > Error log file after 2021-07-25 nightly > > > > I've exported and attached the error log containing the stack trace for > > this, after updating to the July 25 nightly build. > > !SESSION 2021-07-26 13:49:51.587 > ----------------------------------------------- > eclipse.buildId=4.20.0.I20210611-1600 > > That is definitely *not* Juli 25 nightly build. Then I don't know how to install the nightly. I started with the 2021-03 release, and added the update site for https://download.eclipse.org/eclipse/downloads/drops4/I20210725-1800/ and updated to the latest JDT, and the problem still occurred. (In reply to Andrey Loskutov from comment #9) > (In reply to Christopher Tubbs from comment #7) > > Created attachment 286833 [details] > > Error log file after 2021-07-25 nightly > > > > I've exported and attached the error log containing the stack trace for > > this, after updating to the July 25 nightly build. > > The logs from this old 4.20 build show bug 574468 stack. So if the same > stack is produced with latest 4.21 build, this issue is a duplicate of bug > 574468 (or vice versa). > It could be a duplicate of bug 574468 (or rather, that is a duplicate of this one). But, it's not the same as bug 574257, as it was originally marked. > If that is the case: could you try to reduce the problem you see to a simple > example that uses only SDK (no maven, gradle, whatever else 3rd party > library), so it could be easier to analyze? The problem is 100% reproducible by simply importing the Apache Accumulo project, as described in the first comment, using the eclipse-java-2021-06-R-linux-gtk-x86_64.tar.gz out of the box... no extras installed at all. I don't know how to make it any easier.
*** Bug 574468 has been marked as a duplicate of this bug. ***
This bug is still valid for 4.21.0 (2021-09), build id 20210910-1417. This makes JDT unusable for me since 2021-03. The steps I provided to reproduce this still reproduce it 100% reliably. Here's the error from my most recent attempt: eclipse.buildId=4.21.0.I20210906-0500 java.version=15.0.2 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product org.eclipse.jdt.core Error Mon Sep 20 20:58:41 EDT 2021 Errors running builder 'Java Builder' on project 'accumulo-core'. java.lang.NullPointerException: Cannot read the array length because "this.fields" is null at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getField(BinaryTypeBinding.java:1418) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.convertMemberValue(BinaryTypeBinding.java:151) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createAnnotation(BinaryTypeBinding.java:199) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createAnnotations(BinaryTypeBinding.java:212) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createFields(BinaryTypeBinding.java:847) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:611) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:1055) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:1036) at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:308) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:257) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:114) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:248) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:252) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:551) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:623) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:452) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:525) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:895) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:145) at java.base/java.lang.Thread.run(Thread.java:832)
I also tried just deleting the affected files. But, then when the project rebuilt, it would identify entirely different files with the same error. The files it identifies and fails on don't seem to have anything clearly in common. So, it's very hard to try to create a smaller project that simulates the problem.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/186332
I could reproduce it with Accumulo - https://github.com/apache/accumulo - I've got the same stack trace, during parsing this huge enum class: https://github.com/apache/accumulo/blob/main/core/src/main/java/org/apache/accumulo/core/conf/Property.java It seems, that the pattern of: enum MyEnum { X, @MyAnnotation(MyEnum.X) Y, } could trigger the bug, however something other is must be there, because if I just have this enum + annotation in a project, I couldn't trigger the bug. As visible from the stack trace: BinaryTypeBinding.cachePartsFrom is called, and this tries to set up the 'fields' by calling the createFields(...) method in the 'if (needFieldsAndMethods) {...}' block. However, in that function, for all the created fields the 'setAnnotation(createAnnotations(...))' is called, which result in getting the same ReferenceBinding from the LookupEnvironment - however, the 'fields' array is not yet initialized.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186625
Sorry, the last gerrit change contained a wrong id, so it is added here, and now I can't remove it.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/186843
Any comment on the patch?
(In reply to Zsombor from comment #19) > Any comment on the patch? A test should be added. Note: I'm not familiar with this code, please check for git history & add appropriate committers as reviewers to the patch.
I can confirm that this bug still exists for Eclipse 2021-12.
Unfortunately, I couldn't find an easy way to add a testcase for this, could someone suggest a similar testcase, which I can extend?
(In reply to Zsombor from comment #22) > Unfortunately, I couldn't find an easy way to add a testcase for this, could > someone suggest a similar testcase, which I can extend? Could you please describe the problem you fix? That will help me understand this better for reviewing and also make it easier to suggest a testcase.
I hope the lack of a test case doesn't prevent a fix from getting applied. I understand that it may be difficult to test for automatically, but the bug is 100% reproducible with the multi-module project I provided. So, it's definitely possible to manually test for and verify a fix. If I understood why it was happening, I would try to provide a more minimal project to test with, but I really don't understand Eclipse code to know why it's happening.
I have added a testcase to the patch. I am sure this can further be simplified, but I couldn't find time to do it. Feel free to make it shorter if possible. However, I still see the test failing even with the patch. And the stack is somewhat different from the original one reported. So, it's possible that my testcase captures a different scenario? In any case, hope this unblocks you.
I can confirm that this bug still exists for Eclipse 2022-03, and Eclipse continues to be unusable by me for this bug. I will continue using 2021-03, updating all components except for JDT, until that also stops working.
(In reply to Zsombor from comment #22) > Unfortunately, I couldn't find an easy way to add a testcase for this, could > someone suggest a similar testcase, which I can extend? Zsombor, can you take a look at the testcase I attached and my comment #25?
(In reply to Jay Arthanareeswaran from comment #27) > (In reply to Zsombor from comment #22) > > Unfortunately, I couldn't find an easy way to add a testcase for this, could > > someone suggest a similar testcase, which I can extend? > > Zsombor, can you take a look at the testcase I attached and my comment #25? Thanks for the test case, it was very valuable! It seems, that my previous fix was not correct, and there was another codepath, where the execution could reach the same BinaryTypeBinding - which is not fully constructed, I don't understand, why I haven't noticed that issue earlier. In the latest patch, I've added a new flag to the ReferenceBinding - 'isFullyResolved', which became true only after 'this.fields' or 'this.components' is not null. Adding this check to convertMemberValue(...) fixed the issue, because now it will return ElementValuePair.UnresolvedEnumConstant(...), which is handled correctly further up the stack. At least, the new test case is green now, and opening up the Accumulo project works.
Are there any nightly builds I can test this with? If something newer is working, I'd like to get my dev environment up-to-date with something that supports Java 17 without this bug, even if it's a nightly build. Currently, I'm still stuck on 2021-03.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/186332 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5be8219af23e7058dcba3e8937d55bb44dbcf763
(In reply to Christopher Tubbs from comment #29) > Are there any nightly builds I can test this with? Please check tomorrow's nightly build on this page: https://download.eclipse.org/eclipse/downloads/
(In reply to Andrey Loskutov from comment #31) > (In reply to Christopher Tubbs from comment #29) > > Are there any nightly builds I can test this with? > > Please check tomorrow's nightly build on this page: > https://download.eclipse.org/eclipse/downloads/ Normally, I'd download the eclipse-java-*-linux-gtk-x86_64 package, the latest release is: https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/2022-03/R/eclipse-java-2022-03-R-linux-gtk-x86_64.tar.gz I don't see an equivalent nightly build at that site. So, I tried to add the update site to my existing installation. It didn't work, because of dependency problems. Which nightly should I download that is equivalent to what I normally download?
(In reply to Christopher Tubbs from comment #32) > (In reply to Andrey Loskutov from comment #31) > > (In reply to Christopher Tubbs from comment #29) > > > Are there any nightly builds I can test this with? > > > > Please check tomorrow's nightly build on this page: > > https://download.eclipse.org/eclipse/downloads/ > > Normally, I'd download the eclipse-java-*-linux-gtk-x86_64 package, the > latest release is: > > https://www.eclipse.org/downloads/download.php?file=/technology/epp/ > downloads/release/2022-03/R/eclipse-java-2022-03-R-linux-gtk-x86_64.tar.gz > > I don't see an equivalent nightly build at that site. So, I tried to add the > update site to my existing installation. It didn't work, because of > dependency problems. Which nightly should I download that is equivalent to > what I normally download? You seem to use "packages". AFAIK they only get updates on milestone builds, that means, you have to wait for 4.24 M1 build of the appropriate package. But I might be wrong, because I don't use them and don't know what is the update strategy there.
(In reply to Andrey Loskutov from comment #33) > You seem to use "packages". AFAIK they only get updates on milestone builds, Well, if there's another way to get Eclipse IDE with JDT running, I don't know how. If others are confident this is fixed and will be included in the next milestone, I don't mind waiting.
Okay, I was able to get everything building and working fine with a bare minimum install of the dev stream Platform, and manually adding optional JDT and M2E features. Assuming nothing changes, it looks like this should be fixed in the next release. Any chance of it being backported as an update to JDT for 2022-03, so it can work on a current release? Working installation: Version: 2022-06 (4.24) Build id: I20220410-1800 Eclipse JDT Plug-in Developer Resources 3.18.1200.v20220410-1800 org.eclipse.jdt.source.feature.group Eclipse Java Development Tools 3.18.1200.v20220410-1800 org.eclipse.jdt.feature.group Eclipse Platform 4.24.0.I20220410-1800 org.eclipse.platform.ide Eclipse Platform 4.24.0.v20220410-1800 org.eclipse.platform.feature.group Equinox p2, Provisioning for IDEs. 2.4.1600.v20220329-1456 org.eclipse.equinox.p2.user.ui.feature.group M2E - Maven Integration for Eclipse (includes Incubating components) 1.20.1.20220227-1319 org.eclipse.m2e.feature.feature.group M2E - POM Editor using LemMinX language server (includes Incubating components) 1.18.4.20220127-1634 org.eclipse.m2e.lemminx.feature.feature.group m2e extension for the Mycila license plugin. 1.1.0 org.basepom.m2e.mycila_license.feature.feature.group If anybody is interested, I also have two other bugs that would be really nice to have fixed for 2022-06: https://bugs.eclipse.org/bugs/show_bug.cgi?id=565271 - Improper handling of terminally deprecated warnings, inconsistent with JLS, forces you to suppress `"removal"` warnings, which Eclipse doesn't even recognize as being needed. https://bugs.eclipse.org/bugs/show_bug.cgi?id=550228 - Deleting projects from Eclipse that depend on each other causes a failure because projects start rebuilding before all the deletes are done - easy fix would be to close all selected projects before deleting all selected projects, or just prioritize deleting projects over any automatic-rebuilds.
(In reply to Christopher Tubbs from comment #35) > Okay, I was able to get everything building and working fine with a bare > minimum install of the dev stream Platform, and manually adding optional JDT > and M2E features. Assuming nothing changes, it looks like this should be > fixed in the next release. Thanks for validation! > Any chance of it being backported as an update to > JDT for 2022-03, so it can work on a current release? Nope. We don't have man power to provide maintenance releases. > If anybody is interested, I also have two other bugs that would be really > nice to have fixed for 2022-06: Best way to get that into next release is to contribute a patch. Just in case you really need it.
(In reply to Andrey Loskutov from comment #36) > Best way to get that into next release is to contribute a patch. Just in > case you really need it. Unfortunately, I don't have sufficient expertise with Eclipse.
