Latest IcedTea7 forest sync

Andrew Hughes ahughes at
Wed Nov 7 12:07:10 PST 2012

This patch:

brings in a number of changes from the IcedTea7 forest which probably need
a little explanation and/or warning.

There are three changes coming in, one new and two the upstreaming of existing

1.  Enabling the unlimited crypto policy

We've had a patch in IcedTea for a long time which deleted a number of crypto
classes related to enforcing a policy on what algorithms/keysizes could be used.
While this works as a quick solution, it's obviously not going to be acceptable upstream.
The default OpenJDK build has always installed a limited policy, based on
export restrictions.  There was an option in the OpenJDK makefiles for an unlimited
policy, but there was no way of enabling it.  With this patch:

we added a UNLIMITED_CRYPTO make flag to allow the unlimited policy to be enabled.
This supersedes the previous IcedTea patch.  The last merge restored the deleted
classes (it made sense to do it then as one was altered upstream) and, with this
patch and UNLIMITED_CRYPTO set in, the unlimited policy should now
be installed.  The attached Java file can test a build is using unlimited crypto
and I suggest that those packaging IcedTea run these as part of their usual
testing procedures.

2.  Addition of Mark Wielaard's upstream version of the SystemTap support patch

This patch:

was finally added upstream.  I've backported this to the IcedTea7 forest and removed
systemtap.patch in IcedTea7.  The testcase mentioned by Mark here:

and Lukas' patch:

also needed to be added, but both should be trivial.  Before we do this, I'd like
to know that we haven't broken SystemTap support in the process, so could someone
please verify that everything is still working as it should with IcedTea7 HEAD? :-)

Note that the --enable-systemtap option is now gone.  You always get SystemTap support
if sdt.h is present and up-to-date enough.  configure will warn if this isn't the case,
but no longer fail (so those who don't want SystemTap support can still build).  We can
consider having an option which makes the failure fatal again if people want it.

3.  Allowing default NSS provider to fail silently when the user configures it

We've had a long standing bug:

whereby, if the user initialises the PKCS11 provider, it can conflict with the configuration
added to the JDK by --enable-nss.  With this patch,

and the addition of handleStartupErrors = ignoreMultipleInitialisation to, the provider
in the JDK will now silently fail to load if the user configures PKCS11, rather than crashing the VM.

Hope that helps,
Bug reports welcome as always.
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (

PGP Key: 248BDC07 (
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

More information about the distro-pkg-dev mailing list