IcedTea6 1.2 Released!

[Mark Wielaard]

Hi Anthony,

On Wed, 2008-07-09 at 19:26 -0700, Anthony Green wrote:
> I got on my flight that day and looked at the IcedTea src tree for the 
> first time, then quickly realized I wasn't going to be able to do this 
> in a vacuum.
> 
> First question for the IcedTea hackers:  where in the tree should my 
> source code live?  It looks like there are a few viable spots.

Yes, there are indeed a couple of ways to extend icedtea/openjdk
depending on how big and how invasive your change is.

For smaller changes the simplest way is to just add a patch under
patches/icedtea-your-cool-hack.patch and then add that to the
ICEDTEA_PATCHES in the Makefile.am. Your change will then be applied
against the openjdk sources before any other building starts and then be
build as if the change was already part of openjdk itself.

For larger changes that mainly involve new classes/files/packages it is
easier to use the overlay mechanism. This is used by Gervill for
example, and is easier when you need to patch/override binary files
(like the color profiles). This seems most appropriate to your case. You
put your files under overlays/openjdk/jdk/src/share/classes/com/package
that either completely overrides the existing classes there or that adds
completely new files. If it is a new package then it is necessary to
combine it with a small patches/icedtea-your-package.patch file to
adjust the build system to pick up your new package
(icedtea-gervill.patch and icedtea-rhino.patch give some examples of
this).

Finally you can build your extension after the core icedtea has been
build, using the just build icedtea and then adding the extension to the
jdk-image. This is how the gcjwebplugin applet and netx webstart support
are done. This does mean that you are basically responsible for the
build of your extension yourself in a separate target in Makefile.am
that you then add as a dependency of stamps/icedtea.stamp. And in that
target you then copy over the results into the correct image dirs. See
the ICEDTEAPLUGIN_TARGET in Makefile.am for an example or the
extra-lib/about.jar for a java extension. If you don't like the previous
solution, then this might be the one to use, although it is a bit more
work, but gives you more flexibility.

There are some other things to take care for if your change is actually
replacing the runtime, like the cacao, zero and shark integration, or
when it is needed in the bootstrap phase (but perhaps not during the
phase after that). Then you have to instruct configure.ac to pick up the
right build pieces and then passing them to the rest of the build
through the ICEDTEA_ENV and/or ICEDTEA_ENV_ECJ in Makefile.am. But those
don't apply to your case.

Cheers,

Mark