Bugzilla – Full Text Bug Listing
| Summary: | Detail formatter could not resolve existing type | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ulli Hafner <Knut.Friedhelm> | ||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | darin.eclipse, glevin | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Ulli Hafner
If you could boil this down to a simple sample project it would help debug the problem. Created attachment 174267 [details]
Projects that expose the bug
Two eclipse projects that expose the bug.
You can reproduce the bug with the following steps: 1. Debug the FormatterTest as a unit test (or plug-in unit test) 2. Stop with a breakpoint at line 12 3. Add a new detail formatter for the selected variable 'demo' 4. Enter 'java.lang.String' as FQN 5. Enter 'formatter.Formatter.format(this)' as snippet 6. After pressing ok, the Variables view shows the error Detail formatter error: could not resolve type: formatter.Formatter This is because the type "java.lang.String" does not have visibility to "formatter.Formatter". Detail formatters are compiled/executued in the context of the type the formatter is associated with. Referenced types are retrieved from the classloader assocaited with this type (String). The class loader used to load "java.lang.String" (which is the bootstrap class loader), does not have visibility of the type "formatter.Formatter". I see. But compilation and CRTL-SPACE seems to resolve this type (otherwise you won't be able to close the window). Shouldn't these features be in sync with the dynamic class loading resolution? And one more thing: isn't the main reason for adding a detail formatter the ability to change the toString() formatting of an existing not-changeable type? I.e., you have a library with type T that has no (good) toString. Then you add a new formatter in your own code that improves the output. That will not work if the library classloader is used. Yes, unfortunately content assist is not in synch since content assist is project based (not class-loader based). A system library is associated with one project in the workspace (although it is referenced by many). The java model will pick one project to associate the JRE with. I agree that it would be nice to synch code assist such that the user cannot create expressions that will not execute, and that it is useful to enhance objects with details... Depending what details you want to add, this is still possible, but having more code in the detail formatter itself, rather than referencing another class to do the formatting. I have the same problem, but I found that once the detail formatter class is loaded, the error goes away. So if I open a Watch expression and use the formatter, or if the program has already used the formatter, no error. I don't understand why Watch works, but Inspect and Variables display does not. Anyway, people can try that as a work around. More details. I had this working fine (with my workaround) and then it stopped. I had added another project to the workspace. If the other project is open, my detail formatter expression "cannot be resolved to a type". Without the other project (which comes alphabetically earlier than the one I am debugging, if that matters), the workaround works again. This suggests that the classloader used is dependent on more than the type of the expression being formatted. I am using a static method to format Map and Collections, which should be base classes. (In reply to comment #8) > I have the same problem, but I found that once the detail formatter class is > loaded, the error goes away. So if I open a Watch expression and use the > formatter, or if the program has already used the formatter, no error. I don't > understand why Watch works, but Inspect and Variables display does not. > > Anyway, people can try that as a work around. 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. |