[patch] RFC: Netx plugins

[Thomas Fitzsimmons]

Francis Kung wrote:
> Hi,
> 
>>> See attached for a patch that changes gcjwebplugin to run applets 
>>> through Netx, consolidating IcedTea "web services" into one place.  
>>> An overview of the major / possibly contentious changes:
>>>
>>> - added an "icedtea-compile" stamp in the makefile for the actual 
>>> OpenJDK build.  This is needed as the new IcedTea is used to build 
>>> netx (I've introduced some API changes, relaxing visibility in 
>>> sun.applet.*).  Note that the lack of "touch 
>>> stamps/icedtea-compile.stamp" is intentional, to remain consistent 
>>> with current behaviour.
>>
>> It's fine to change the current behaviour (i.e., require removal of 
>> stamps/icedtea-compile.stamp to force a rebuild) as a convenience for 
>> people working on tools.jar/netx.jar.
> 
> I've assumed that more people will be working on OpenJDK than 
> netx/tools.jar, and so those who would find it convenient can add the 
> touch themselves (ie I have that in my local tree =)  )

Either way is fine.  I just wanted to be sure what behaviour you were 
trying to preserve.  Which is that "make icedtea"/"make icedtea-debug" 
will always cause an OpenJDK rebuild, without the need to first remove a 
stamp file, right?

[...]

>> Can the NetX packages be included in rt.jar so that no use of 
>> reflection is required?  Can NetxPanel and PluginBridge go in the 
>> sun.applet package to eliminate the API changes?
> 
> Originally I was looking for ways to avoid the API changes... I've 
> considered:
> 
> a) putting NetxPanel and PluginBridge in rt.jar; however that would mean 
> rt.jar requires netx.jar in order to compile and run... in which case, 
> we may as well put all of the netx code in rt.jar somewhere and 
> eliminate netx.jar altogether.  I don't think rt.jar should depend on an 
> external module.

Agreed; I'm suggesting the "put all of the netx code in rt.jar" 
approach.  The only downside I can think of is that IcedTea wouldn't 
provide a standalone javaws.jar replacement.  But we could just symlink 
javaws.jar to rt.jar as we've done for JVM extension jars in the Fedora 
IcedTea package.

Tom