Suppress NPE in JDT LookupEnvironment
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- java
- Bereich
- testing-qa
Rechercherichtung
Start with the failing workflow run and trace the test teardown around the reported LookupEnvironment stack trace. Read the test lifecycle code and the AfterEachCallback extension guidance in the issue; done means this expected NPE no longer fails the tests and teardown still runs through the intended callback.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
As seen in https://github.com/eclipse-windowbuilder/windowbuilder/runs/109588061970.
!MESSAGE Designer [1.26.0.202609291849.202609291858]: Cannot read the array length because "signature" is null
!STACK 0
java.lang.NullPointerException: Cannot read the array length because "signature" is null
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromConstantPoolName(LookupEnvironment.java:1918)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromConstantPoolName(LookupEnvironment.java:1937)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:463)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:1077)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:1058)
at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:307)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:296)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:116)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:251)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:252)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:3341)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1374)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1646)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:666)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1326)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:791)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateASTCached(ASTParser.java:1248)
at org.eclipse.jdt.core.dom.ASTParser.lambda$0(ASTParser.java:1126)
at org.eclipse.jdt.internal.core.JavaModelManager.cacheZipFiles(JavaModelManager.java:5765)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1126)
at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:874)
at org.eclipse.wb.internal.core.utils.jdt.core.CodeUtils.parseCompilationUnit(CodeUtils.java:113)
at org.eclipse.wb.internal.core.utils.jdt.core.CodeUtils.parseCompilationUnit(CodeUtils.java:97)
at org.eclipse.wb.internal.core.utils.ast.AstEditor.<init>(AstEditor.java:118)
at org.eclipse.wb.internal.core.parser.JavaInfoParser.<init>(JavaInfoParser.java:207)
at org.eclipse.wb.internal.core.parser.JavaInfoParser.parse(JavaInfoParser.java:148)
at org.eclipse.wb.internal.core.editor.DesignPage.internal_refreshGEF(DesignPage.java:520)
at org.eclipse.wb.internal.core.editor.DesignPage$3.run(DesignPage.java:438)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:124)
The failure happened when testing against the 2024-06 Eclipse and the LookupEnvironment class looks completely different now. Even if a similar problem still exists, it would not have a different stack trace. In any case, there is nothing we can really do here, so it should not cause the tests to fail.
As an additional note: Failing while tearing down the test case is likely not a very good idea, because it risks leaving stale resources behind. It should probably be moved to an AfterEachCallback extension.
- Vorherrschende Sprache
- Java
- Sterne
- 97
- Forks
- 34
- Ø Merge
- 3 T. 15 Std.
- Gemergte PRs (30 T.)
- 9
Entwicklungsumgebung
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus eclipse-windowbuilder/windowbuilder
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 86/100
-
WindowBuilder 1.26.0Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 40/100
eclipse-windowbuilder/windowbuilder#1635 · 2 Kommentare ·
-
good first issue
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 65/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 70/100
Alle Issues in eclipse-windowbuilder/windowbuilder
Ähnliche Issues
-
bug main ui
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
openhab/openhab-webui#4671 ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
NearVanilla/IceCream#109 ·
Maintainer antworten meist innerhalb von 1 Tag
-
getRawTextContent() returns the lines of every page in reverse order (bottom to top) since 4.0.3Offen
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 90/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
bancolombia/bin-stash#79 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag