Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 95278

Summary:	PDE does not reset the JRE profile on a cached state
Product:	[Eclipse Project] PDE	Reporter:	Wassim Melhem <wassim.melhem>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jeffmcaffer, tjwatson
Version:	3.0
Target Milestone:	3.1 RC1
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Wassim Melhem

2005-05-14 16:42:13 EDT

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?

Comment 1 Wassim Melhem

2005-05-16 11:18:17 EDT

at the risk of coming across as testy (yet again :-), but Tom, we need your 
input as soon as you can give it.

Comment 2 Thomas Watson

2005-05-16 11:42:32 EDT

>>  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.

Comment 3 Wassim Melhem

2005-05-16 11:59:55 EDT

>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.

Comment 4 Wassim Melhem

2005-05-16 19:40:52 EDT

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.