Bugzilla – Full Text Bug Listing
| Summary: | intermittent failures in CompletionTests2.testBug151500a() | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana |
| Version: | 4.7 | ||
| Target Milestone: | BETA J9 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
To add some weirdness: testBug151500a() uses an inconsistent combo of JCL_LIB15 and compliance of "1.4". That would perhaps explain, why j.l.Object is not found (thus letting the test pass). OTOH, testBug281598c() looks consistent with JCL_LIB and implicit "1.4". The test _could_ easily be fixed by putting this into some suitable location: javaProject.setOption(AssistOptions.OPTION_SubstringMatch, AssistOptions.DISABLED) But I'm uncomfortable with that, given the tests actually pass in production builds plus the fact that s.o. accidentally makes "use" of a broken configuration with no JCL_LIB available on the classpath. Are others seeing the failures as well, or is there s.o. spooky on my machine? Perhaps an IDE-only issue? I just tried on my machine and happens here as well. 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. *** This bug has been marked as a duplicate of bug 519424 *** |
Debugging CompletionTests2 I observed: - testBug151500a() may fail when running the full test class - it doesn't fail when run in isolation - it doesn't fail when stepping through CompletionEngine.findMethods(..) - when it succeeds, the currentType representation of j.l.Object is a MissingTypeBinding Symptom of failure: unexpected methods from Object are proposed -- as sub-word proposals I assume, since none of the methods is a prefix match for the selector prefix "s": equals[METHOD_REF]{equals(), Ljava.lang.Object;, (Ljava.lang.Object;)Z, equals, (obj), 30}\n getClass[METHOD_REF]{getClass(), Ljava.lang.Object;, ()Ljava.lang.Class;, getClass, null, 30}\n hashCode[METHOD_REF]{hashCode(), Ljava.lang.Object;, ()I, hashCode, null, 30}\n toString[METHOD_REF]{toString(), Ljava.lang.Object;, ()Ljava.lang.String;, toString, null, 30}\n Things to investigate: - is JCL_LIB15 resolved? - is this resolving affected by concurrency or other non-deterministic stuff? - are subword proposals expected in this context? Similar for testBug281598c() in the same class.