[patch] RFC: Netx plugins
fkung at redhat.com
Tue Feb 12 10:23:18 PST 2008
>>>> - 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
>> 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...
More information about the distro-pkg-dev