Bugzilla – Full Text Bug Listing
| Summary: | [model] Source range unavailable for binary enums from JDK after fixing compiler compliance | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | jerome_lanneluc, Olivier_Thomann, srikanth_sankaran |
| Version: | 3.4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Markus Keller
Sorry but we don't have access to a Mac here. Is it possible to reproduce on another platform? It is weird that the behavior is different from one platform to another one since we don't have platform dependent code in this area. I guess I can have access to the releng machine that runs on MacOS. Let me know if you want me to investigate it. Sorry, the Mac specificity was a red herring; changed summary. This problem can also be reproduce under WinXP as follows: - new workspace - install 1.5 JDK - new Java Project, set compiler compliance to 1.4 - close and reopen project to flush cache => RetentionPolicy and its children don't have source ranges (OK, due to parsing errors) - set compiler compliance to 1.5 => RetentionPolicy and its children still don't have source ranges (this is the bug) - close and reopen project to flush cache => Source ranges are OK now ===> The problem is that the Java element cache is not flushed when the compiler compliance is corrected. In my original setup, I had a workspace with only an 1.5 JDK and all projects set to 1.4 compliance. Then I added a project with 1.5 compliance. When I opened RetentionPolicy from that 1.5 project, I still got an editor for RetentionPolicy from one of the 1.4 projects. ===> The fix needs to make sure that a type from a JDK is always opened in the context of the project with the latest available JDK, and not just in any project that refers to the JDK. See also bug 106603 Is there agreement we can close this as a duplicate of bug 201244 ? Or is there anything specific to this bug that is not captured by bug 201244 ? Bug 201244 and bug 106603 are only concerned with single-project scenarios. But this part of comment 3 shows a problem on top of that: > In my original setup, I had a workspace with only an 1.5 JDK and all projects > set to 1.4 compliance. Then I added a project with 1.5 compliance. When I > opened RetentionPolicy from that 1.5 project, I still got an editor for > RetentionPolicy from one of the 1.4 projects. > > ===> The fix needs to make sure that a type from a JDK is always opened in the > context of the project with the latest available JDK, and not just in any > project that refers to the JDK. I would keep this bug for the problem with mixed compiler compliances in the same workspace with the same JREs. I've set the severity to minor, since this doesn't seem to affect many people and the fix will probably be quite difficult to implement efficiently (you would basically have to compare the compliances of all projects in the workspace that have the same JRE on their classpath). 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. |