[patch] RFC: Netx plugins

[Francis Kung]

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

Yes.  Of course, if we are looking to eliminate the API changes (as 
below), this becomes moot.. =)

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

I'm not opposed; I think the easiest way to do this would be to treat 
netx (without NetxPanel and PluginBridge) as a binary plug, compile it 
all during the build-plugs stage, and patch the OpenJDK make files to 
import them during the OpenJDK build.  If we do this, it could be a good 
opportunity to clean up the netx package names too, so they follow 
"proper" conventions =)

Another possibility (which I don't have time to experiment with soon, 
unfortunately) would be to have NetxPanel extend AppletPanel, instead of 
AppletViewerPanel.  From a quick glance, that might eliminate (some? 
all?) API changes at the cost of some code duplication...

Regards,
Francis