| Summary: | NPE when launching JUnit tests by right clicking project | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | jeps <petteri.stenius> | ||||
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jarthana, sarika.sinha, stephan.herrmann | ||||
| Version: | 4.5.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows NT | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
jeps
Please attach the sample project which causes NPE. Transferring to JDT Core for further comments. Looking at the code, we somehow end up with a super interface name of null. Possibly something is going wrong with the calculation of start/end. It would be nice to have a testcase, though. I'm sorry I cannot easily send the project causing the NPE. I have not been able to isolate the issue into a sample project. Please let me know if there's anything else I could do. Created attachment 259347 [details]
Eclipse486222.java
By going backwards in my SCM i was able to identify the code change that causes the failure. The code is in the attachment Eclipse486222.java. If this file exists in a project's src/main/java tree then running JUnit tests for the project fails with NPE. The code has a static method that defines a local class, where the local class name ends with a '$' character. If I rename the local class to something more appropriate without special characters then everything works ok. (In reply to jeps from comment #5) > By going backwards in my SCM i was able to identify the code change that > causes the failure. > The code is in the attachment Eclipse486222.java. If this file exists in a > project's src/main/java tree then running JUnit tests for the project fails > with NPE. > The code has a static method that defines a local class, where the local > class name ends with a '$' character. If I rename the local class to > something more appropriate without special characters then everything works > ok. Thanks for the analysis, but: Outch, that looks like asking for trouble. The binary name of that local class is eclipse486222/Eclipse486222$1Predicate$ I guess when we see the first '$' we start trying to interpret '$' as the separator for nested classes, not part of a class name. Then when we encounter the second '$' we assume a second-level nested class, but we end up with no name for that second nested class -> NPE I'm not even sure if avoiding the NPE on our side is the best course of action, because quite likely that would just mask the underlying problem, without really supporting that strange class in functionality like search & hierarchy lookup. To fully support all combinations of class nesting and source-level names including '$' would require to testing all possible interpretations with lots of accesses to the file system, like, if we have a type a$b$c, we need to check existence of - c as nested in (b nested in a) - class with source name b$c nested in a - c nested in class with source name a$b - class with source name a$b$c More dollars cause combinatorial explosion. I believe (without having checked the sources) we typically assume '$' is *either* a part of the name *or* the nested class separator, but don't account for it playing both roles within the same binary name! And: there are lots of locations in the code that deal with the problem of interpreting '$'. 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. If you have further information on the current state of the bug, please add it. 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. |