Community
Participate
Working Groups
Build: 3.1M7 On a fresh workspace, PDE creates a new state and sets the JRE profile on it. This results in the following behavior: if there is a plugin X in the workspace that depends on org.eclipse.osgi, when PDE asks the runtime what packages are visible to X, the runtime returns the osgi packages along all the packages (javax.*, etc.) from the jre profile. PDE then creates an access rule for each package and sets it on the org.eclipse.osgi classpath entry. 2. Shut down and restart. 3. Since no changes happened between the shutdown and restart, PDE restores the state from 1. that it had cached. However, we do NOT reset the profile on it. Therefore, this time when ask the runtime what packages from org.eclipse.osgi are visible to X, it only returns the osgi packages. It does NOT return the packages from the JRE. So the classpath looks now different to JDT and a false rebuild occurs. 4. You can shut down and restart as many times as you want and this problem will not reoccur of course because we never reset the jre profile on a cached state, so the classpath returned to jdt will always be the same. Questions: 1. Is it still necessary for pde to set the jre profile on the state after the runtime backed out of the boot delegation enhancements? 2. Should we reset it on the cached state or is that a runtime bug? 3. If the jre profile is set, then some 100+ package prefixes listed in the profile will be unnecessarily added to any classpath entries referencing osgi.jar. This is totally unnecessary. Can the runtime ignore these packages when PDE asks it for visible packages?
at the risk of coming across as testy (yet again :-), but Tom, we need your input as soon as you can give it.
>> 1. Is it still necessary for pde to set the jre profile on the state after >> the runtime backed out of the boot delegation enhancements? IMO, yes PDE should still set the jre profile. I would still like to allow bundles to import packages which they want from the JRE. If you do not set the profile then these bundles will not resolve >> 2. Should we reset it on the cached state or is that a runtime bug? Sounds like a bug in runtime on the surface. Are you setting the platform properties at all on the cached state (using State#setPlatformProperties)? It sounds like PDE is calling this method on the cached state but is not setting the org.osgi.framework.system.packages property in the Dictionary object. If this is the case the it is a PDE bug because we would compare the null value with the cached version and detect a change. I will try to confirm what is going on here ... >> 3. If the jre profile is set, then some 100+ package prefixes listed in the >> profile will be unnecessarily added to any classpath entries referencing >> osgi.jar. This is totally unnecessary. Can the runtime ignore these >> packages when PDE asks it for visible packages? IMO, no. This is the same as 1) If this turns out to be an issue then I can be convinced to not have PDE set the java profile on the State because the tools are not ready for this level JRE modularity. But if PDE does set the jre profile then getVisiblePackages should return ALL packages the runtime thinks the bundle can access.
>But if PDE does set the jre profile then getVisiblePackages should return ALL >packages the runtime thinks the bundle can access. All I really care about is this point. what will it take for you to budge? Every plugin in the universe depends on org.eclipse.osgi, jdt will be faced with 100+ access restrictions on osgi.jar where we know for a fact that none of these packages exist. We can still set the jre profile and accomodate users who want to import packages from the jre, if you want. Note that PDE has no control over the JRE container, so whatever access restrictions regarding jre profiles cannot be enforced at development time anyway.
Fixed the PDE issue in that since we save the state prior to setting the platform properties, we reset them at every startup. As for the fact that system packages (e.g. javax.*) are returned by the state helper as legitimate exported packages is addressed in bug 95476 in the Platform/Runtime bucket.
