[patch] RFC: Netx plugins
fitzsim at redhat.com
Thu Feb 7 10:05:52 PST 2008
Francis Kung wrote:
>>> 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
> 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
More information about the distro-pkg-dev