Community
Participate
Working Groups
In RC1. 1) Pull up the properties on a project. 2) Go to Libraries, and drill down to JRE System Library > rt.jar > Native Library Location. 3) Select "Edit..." 4) Browse to any folder that has no libraries in it ("My Documents" works well) 5) Hit OK: My Documents is displayed under rt.jar 6) Hit OK to close Properties 7) Re-open properties, and drill back down: rt.jar shows Native Library Location: (None)
This is a bug in launching. We set the attribute correctly (verified by debugging it) but the JRE container doesn't persit it. So the information is lost. Moving to Debug.
The JREContainerInitializer gets a callback to requestClasspathContainerUpdate with the new settings. We need to look for changes to the native attribute.
CC'ing Dirk & Philippe. The JRE container does not currently persist associcate native library or access rule annotations that the build path page allows to append to JRE library entries. The "installed JREs" edit dialog only allows for javadoc and library location to be editor, so we are inconsistent in this manner. This would require the LibarayLocation be changed (API additions) to allow for the persistence of access rules and native library locations. Origianlly, I thought the classpath would simply persist this info, and thus the disconnect. I suggest that we defer this feature for 3.1, to avoid additional API changes. However, is there some way we could have the buildpath page disallow access rule and native entry attributes for JRE containers?
Martin, can we look into filtering them in the UI for 3.1. The user will still be able to set access restrictions on the container itself, but not on the individual Jar. And having a native library for the JRE is uncommon as well.
Will consider in 3.2. For 3.1, access rules and native libs will not be allowed on individual JRE archives (only the root container).
Opening for 3.2. JCORE may need to provide mementos for extra classpath attributes such that we can persist them. The contributor of the attribute should provide the memento so all clients do not have to know how to persist/restore the attributes.
Entered bug 110171 for the JDT Core side of this bug.
Deferred again...forgot this requires new API on LibraryLocation to set/persist a native location on a LibraryLocation. Current behavior is workable as a native can be set on the container itself.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
