Bugzilla – Full Text Bug Listing
| Summary: | [model] o.e.jdt.core.dom.PackageBinding.getJavaElement throwing IndexOutOfBoundsException | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Robert Konigsberg <konigsberg> | ||||
| Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | Olivier_Thomann, stephan.herrmann | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 4.16 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Could you please provide a small code snippet that reproduces the cases where the findPackageFragments(..) is returning an empty array ? Thanks. The call to nameLookup.findPackageFragments(getName(), false) should return null or a non-empty array. This is the way it is documented right now. So once this is fixed, the DOM side should work without any changes. To fix this, we first need to write a regression test. So we need a test case that shows the problem. Robert, can you please provide such a test case? Robert, is this still an issue and do you have the steps to reproduce this bug? Yes, this is still an issue. I'm hopefully going to pick up this code in the not-too-distant future so hopefully I can get you a code snippet before too long. I think one way to help there would be to release some code that adds tracing when the array is empty. This would make it easier to find out what is going on and extract a test case. Robert, Would this help you to get us a reproducable test case ? Jay, I'll take care of it since the problem is inside DOM/AST bindings. If you like. Something I didn't think about during my last reply: Since reporting this bug a teammate has started patching JDT locally (and sending the patches upstream, don't worry) so if I need to pick this up again, we have an out. Created attachment 160109 [details]
Tracing code
Released the tracing code in HEAD. Please let me know if you can provide more details with this tracing. Thanks. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Marking as WORKSFORME since we have tracing in place that was never reported to be triggered. |
Build ID: I20080617-2000 Steps To Reproduce: Visit an AST, stopping at the package name. It's the QualifiedName for a package that is not in the project. I think it's due to it being an upper part of the package. e.g. packages are com.foo.a.b.c.d, and this is the qualified name for com.foo. More information: See getJavaElement: public IJavaElement getJavaElement() { ... IJavaElement[] pkgs = nameLookup.findPackageFragments(getName(), false/*exact match*/); if (pkgs == null) return null; return pkgs[0]; } We're getting cases where findPackageFragments is returning a 0-length array, and it's throwing IOOBE. I suggest if (pkgs == null || pkgs.length == 0) return null;