Community
Participate
Working Groups
If you change the source dir for rt.jar to point at a private copy of the source then the JRE 'manager' thinks that the binaries are coming from an non standard place too. SO the checkbox 'use default system libraries' gets checked off. This is important becuase then programs gets run with explicit classpath set rather than defaulting, this stops JCE from working (or anything that wants trusted code). You have to keep going back to the JRE settings page (and this in turn blows away the source binding)
The JCE problem has been fixed by allowing the bootpath to be pre- pened/appended to. You could leave the classpath alone and instead, only change the source lookup path (put the desired source first on the source lookup path). *** This bug has been marked as a duplicate of 38370 ***
I'll re-open this. The problem here is that changing a source attachment creates a non-default runtime classpath. The classpath is actually unchanged - only the source is different.
repro steps 1. install java source code in, say, c:\javasource 2. ensure JRE set to 'use default lib path' 3. in package explorer browse to rt.jar in some project, choose any class and double click 4. when prompted 'rt.jar has no source code' - point eclipse at c:\javasource 5. now go back to windows preferences and look at JRE. 'use default library path' is checked off
This isn't a bug. You have changed the default source attachment, which means the libs are not in their default settings anymore. We should however display the source attachments in the list, so you can see what they are. This does not affect the bootpath computation when launching.
This is now fixed. The source attachments are displayed as children of the archives (same as in the build path). See bug 89935, where this problem was fixed.
*** This bug has been marked as a duplicate of 89935 ***
