Community
Participate
Working Groups
To reconstruct the bug you need to have at least 2 different JRE's installed on your machine, and have at least 2 different projects open in your workspace. 1) Set Project 1 to use alternate JRE and set it to 1.5. 2) Set Project 2 to use alternate JRE and set it to 1.42. while doing this make sure that the default JRE is 1.42 3) Change the default JRE to 1.5 and move project 2 to use the default JRE. (in the same dialog box). Result: Project to still uses JRE 1.42. The bug is even stranger when you have more than 2 JRE's installed on your machine, try to play with it and you will see that the JRE does change to the third JRE wich is not the JRE selected and not the original JRE that was before you made the change. That is, a chnage occurs not to the right JRE. In anycase the selected JRE is the one that appears in parantheses in the package explorer, and not the one that appears in the Edit Library dialog.
Tobias, can you please have look.
We call: JavaCore.getClasspathContainer(path, project); with path= "org.eclipse.jdt.launching.JRE_CONTAINER" And I get the old 1.4 jre because org.eclipse.jdt.internal.core.JavaModelManager.containerGet(IJavaProject, IPath) returns a cached entry. IMHO core should not cache the default jre container in the project containers. Here are some minimal steps to reproduce: 1. Create a new Project P01 using default JRE 1.5 (to cache it) 2. On P01 'Build Path>Configure Build Path' 3. On Libraries tab select JRE System Library [jdk1.5...] entry 4. Edit 5. Alternate JRE 6. Finish 7. OK 8. Window>Preferences>Java>Installed JREs 9. Select a 1.4 jre as default 10. OK 11. On P01 'Build Path>Configure Build Path' 12. On Libraries tab select JRE System Library [jdk1.5...] entry 13. Edit 14. Select Workspace default 15. Set a breakpoint to JavaModelManager#containerGet 16. Finish Is: Breakpoint is hit, containerGet returns a 1.5 container Should: Return the default 1.4 container
Following steps from comment 0, I see that porject 2 is using JRE 1.42. Maybe I didn't understand what you meant by "in same dialog box". Following steps from comment 2, I see that containerGet returns a 1.4 container. Please reopen if you have more details on how to reproduce it
(In reply to comment #3) I can easily reproduce in I20070517-1700 > Following steps from comment 0, I see that porject 2 is using JRE 1.42. Maybe I > didn't understand what you meant by "in same dialog box". For comment 0, replace step 3 by: 3) Go to JRE Preference page and set default to 1.5 4) Set Project 2 to use the default JRE Is: The Project still uses 1.4, although the default is 1.5 > > Following steps from comment 2, I see that containerGet returns a 1.4 > container. > > Please reopen if you have more details on how to reproduce it > Given a new workspace with two JRE installed: 1.4 and 1.5 (default): 1. Create a new Project P01 using default JRE 1.5 2. On P01 'Build Path>Configure Build Path' 3. On Libraries tab select JRE System Library [jdk1.5...] entry 4. Edit 5. Alternate JRE (select 1.5) 6. Finish 7. OK 8. Window>Preferences>Java>Installed JREs 9. Select 1.4 as default 10. OK 11. On P01 'Build Path>Configure Build Path' 12. On Libraries tab select JRE System Library [jdk1.5...] entry 13. Edit 14. Select 'Workspace default JRE (1.4)' 15. Set a breakpoint to JavaModelManager#containerGet 16. Finish Is: Breakpoint is hit, containerGet returns a 1.5 container Should: Return the default 1.4 container
(In reply to comment #4) > (In reply to comment #3) > For comment 0, replace step 3 by: > 3) Go to JRE Preference page and set default to 1.5 > 4) Set Project 2 to use the default JRE > Is: > The Project still uses 1.4, although the default is 1.5 Thanks Benno. I can reproduce now.
Created attachment 68574 [details] Proposed fix and regression test
*** Bug 136382 has been marked as a duplicate of this bug. ***
Note that 3.2 had the same problem.
Created attachment 72603 [details] Fix with comment and more regression tests
Fix and tests released for 3.4M1 in HEAD.
*** Bug 94740 has been marked as a duplicate of this bug. ***
Verified for 3.4M1 using build I20070802-0800.