March 2012

We are proud to announce the release of GNU Classpath 0.99!

GNU Classpath, essential libraries for java, is a project to create free core class libraries for use with runtimes, compilers and tools for the java programming language.

The GNU Classpath developer snapshot releases are not directly aimed at the end user but are meant to be integrated into larger development platforms. For example JamVM, CACAO and Kaffe can make use of an
installed copy of GNU Classpath 0.99, while GCC (gcj) will use the developer snapshots as a base for future versions. For more projects based on GNU Classpath, see

This release brings with it a number of interesting new features:

  • Addition of java.util.regex.Pattern.quote.
  • Addition of
  • Addition of

There have also been many bugfixes over the past year. Those relevant to 0.99 can be found in our bug database.

With the 0.95 release, we switched fully towards the 1.5 generics work that we previously released separately as classpath-generics. All this work is now fully integrated in the main release and various runtimes
(gcj, cacao, jamvm, ikvm, etc) have been extended to take advantage of the new generics, annotations and enumeration support in the core library. As a consequence, only 1.5 capable compilers (currently the
Eclipse Compiler for Java (ecj) and Sun’s javac) may be used to build Classpath.

The GNU Classpath developers site provides detailed information on how to start with helping the GNU Classpath project and gives an overview of the core class library
packages currently provided.

For each snapshot release generated documentation is provided through the gjdoc tool, which is part of GNU Classpath 0.99. Full documentation on the currently implementated packages and classes can
be found at: We are looking into how to extend the documentation experience in the future. Please contact the mailinglist if you would like to help with this effort.

For more information about the project see also:

GNU Classpath 0.99 can be downloaded from or one of the mirrors

  • File: classpath-0.99.tar.gz
  • SHA256sum: f929297f8ae9b613a1a167e231566861893260651d913ad9b6c11933895fecc8

New in release 0.99 (Mar 07, 2012)

  • Addition of java.util.regex.Pattern.quote.
  • Addition of
  • Addition of
  • Bug fixes:
    • PR39408: gjavah doesn’t generate constants in header files where they occur in a superclass
    • PR40590: namespace namespace broken in CNI
    • PR40630: java.util.Scanner fails when used for charset generation by the OpenJDK build
    • PR40653: Issue with XML stream writer and namespaces
    • PR40663: Support Stax API 1.0.1
    • PR39177: trunk revision 144128 – jar: internal error: java.lang.NullPointerException
    • PR41696: () returns false when it should return true
    • PR43536: CopyOnWriteArrayList bug in delete() when empty
    • PR36560: Error parsing zip file with larger files in it
    • Restrict access to VM classes.
    • Cleanup use of message resources.
    • Throw exception when encrypted zip file entries are encountered.
    • Fix infinite recursion in javax.print.attribute.standard.JobStateReasons.add.
    • Native code cleanups in GtkToolkit.c and jcl.c.
    • Only log when debugging is on.
    • PR44411: System.nanoTime() is not independent of wall-clock time
    • PR46775: Calling Policy.setPolicy with a new Policy object has no effect on the DefaultSecurityManager
    • Use implementation of VMClass.getSimpleName from gcj.
    • Simplify security determination in ProtectionDomain in situations where all permissions are available.
    • PR42390: Missing Security Manager checks in classpath apis
    • Throw NullPointerExceptions appropriately for compatibility with OpenJDK.
    • Use Integer.parseInt in preference to Integer.decode in java.util.Formatter.
    • Use same default capacity in java.util.HashMap as documented in OpenJDK.
    • Check for hashcode equality before calling equals in java.util.HashMap.put
    • Make sure match is within input data limits in java.util.regex.Matcher.find.
    • Fix misuse of ArrayList.set in javax.swing.text.html.StyleSheet.resolveStyle.
    • PR48131: incomplete dynamic bit lengths tree
    • Check for negative capacity in VMDirectByteBuffer’s native code.
    • PR42823: tcp/ip sockets read/write operations causes memory leak
    • Generate META-INF/INDEX.LST for
    • Fix issues when building with -Werror and gcc 4.6.
    • PR40188: javah creates constants using name of superclass
    • PR45527: gjavah encodes $ as used in inner classes as 00024 where Oracle’s javah does not
    • PR45526: gjavah does not implicitly produce header files for inner classes
    • Fix NullPointerException for null keys in java.util.HashMap.put.
    • Fix BEAST security issue in
    • RH712013: pdftk crashes with java.lang.ArrayIndexOutOfBoundsException
  • Updated to libtool 2.x.
  • Lots of warning fixes / addition of generics.
  • Fix license headers in tools.
  • Normalise whitespace.
  • Maintenance work on javac detection.
  • Mark plugin as unmaintained and disable by default.

The following people helped with this release:

We would also like to thank the numerous bug reporters and testers! In addition, we’d like to extend our thanks to all those who’ve contributed over the years and have helped in building a thriving and friendly community around the GNU Classpath project.

The following results are for IcedTea 6 & 7 using the NSS provider but without the hardware AES support enabled. It turns out that testing this scenario doesn’t require changing the NSS code; you merely need to set the environment variable NSS_DISABLE_HW_AES=1.

IcedTea6 with the NSS Provider but no hardware AES

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 7.04 ns/byte, 135MB/s 7.14 ns/byte, 134MB/s 5.93 ns/byte, 161MB/s 6.26 ns/byte, 152MB/s 6.28 ns/byte, 152MB/s 6.39 ns/byte, 149MB/s 6.31 ns/byte, 151MB/s 6.57 ns/byte, 145MB/s
192 bit 7.46 ns/byte, 128MB/s 7.72 ns/byte, 124MB/s 7.18 ns/byte, 133MB/s 7.54 ns/byte, 126MB/s 7.16 ns/byte, 133MB/s 7.27 ns/byte, 131MB/s 7.19 ns/byte, 133MB/s 7.48 ns/byte, 128MB/s
256 bit 8.34 ns/byte, 114MB/s 8.61 ns/byte, 110MB/s 8.25 ns/byte, 116MB/s 8.62 ns/byte, 111MB/s 8.04 ns/byte, 119MB/s 8.16 ns/byte, 116MB/s 8.10 ns/byte, 118MB/s 8.37 ns/byte, 114MB/s

IcedTea7 with the NSS Provider but no hardware AES

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 6.90 ns/byte, 138MB/s 6.81 ns/byte, 140MB/s 5.75 ns/byte, 166MB/s 5.97 ns/byte, 160MB/s 5.65 ns/byte, 169MB/s 5.91 ns/byte, 162MB/s 5.63 ns/byte, 169MB/s 5.89 ns/byte, 162MB/s
192 bit 7.17 ns/byte, 133MB/s 7.34 ns/byte, 130MB/s 6.64 ns/byte, 143MB/s 6.85 ns/byte, 139MB/s 6.54 ns/byte, 145MB/s 6.79 ns/byte, 140MB/s 6.52 ns/byte, 147MB/s 6.78 ns/byte, 140MB/s
256 bit 8.12 ns/byte, 117MB/s 8.23 ns/byte, 116MB/s 7.56 ns/byte, 126MB/s 7.80 ns/byte, 122MB/s 7.43 ns/byte, 129MB/s 7.69 ns/byte, 124MB/s 7.41 ns/byte, 129MB/s 7.67 ns/byte, 125MB/s

There is still a noticeable improvement using the NSS provider, but not as significant as when AES is handled in hardware. This does, however, mean that enabling NSS as the primary provider should show a benefit on all installs, not just ones with hardware AES.

I also found today that Oracle have enabled this provider with a priority of 2 on Solaris builds from jdk7u4 on; see bug 7088989 and this commit. Priority 1 is given to a proprietary provider,, the source of which is not included in OpenJDK.

These were run about the same time as the last set, but didn’t have time to write them up last week.

IcedTea7 With the Default SunJCE Provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 9.47 ns/byte, 100MB/s 10.55 ns/byte, 90MB/s 8.97 ns/byte, 106MB/s 9.62 ns/byte, 99MB/s 8.99 ns/byte, 106MB/s 9.57 ns/byte, 100MB/s 8.96 ns/byte, 106MB/s 9.67 ns/byte, 99MB/s
192 bit 10.42 ns/byte, 91MB/s 11.45 ns/byte, 83MB/s 10.21 ns/byte, 93MB/s 10.98 ns/byte, 86MB/s 10.19 ns/byte, 93MB/s 11.02 ns/byte, 86MB/s 10.19 ns/byte, 93MB/s 11.08 ns/byte, 86MB/s
256 bit 11.54 ns/byte, 82MB/s 12.74 ns/byte, 74MB/s 11.53 ns/byte, 82MB/s 12.23 ns/byte, 78MB/s 11.39 ns/byte, 84MB/s 12.19 ns/byte, 78MB/s 11.50 ns/byte, 82MB/s 12.24 ns/byte, 78MB/s

IcedTea7 With the NSS Provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 2.59 ns/byte, 369MB/s 1.02 ns/byte, 950MB/s 1.63 ns/byte, 588MB/s 0.36 ns/byte, 2857MB/s 1.51 ns/byte, 645MB/s 0.30 ns/byte, 3333MB/s 1.50 ns/byte, 645MB/s 0.29 ns/byte, 3333MB/s
192 bit 2.42 ns/byte, 399MB/s 0.79 ns/byte, 1248MB/s 1.87 ns/byte, 512MB/s 0.39 ns/byte, 2500MB/s 1.79 ns/byte, 540MB/s 0.35 ns/byte, 2857MB/s 1.78 ns/byte, 540MB/s 0.34 ns/byte, 2857MB/s
256 bit 2.89 ns/byte, 332MB/s 0.90 ns/byte, 1109MB/s 2.25 ns/byte, 425MB/s 0.46 ns/byte, 2222MB/s 2.09 ns/byte, 465MB/s 0.40 ns/byte, 2500MB/s 2.07 ns/byte, 465MB/s 0.39 ns/byte, 2500MB/s

So 7 with NSS seems to be faster than 6 with NSS, especially with the larger block sizes. Not too surprising, given it has a newer version of HotSpot.

OpenJDK has long had provision for cryptography support via NSS using the provider, but I get the impression it isn’t widely used or even known about. It requires some configuration to setup, as the OpenJDK build doesn’t look for NSS and the provider thus has to be manually configured with the location of the library. In September 2009, I added support to IcedTea to automate a lot of this, so you can now pass –enable-nss to the build and it will detect NSS and set it up in ${java.home}/jre/lib/security/ I know Matthias Klose (doko) has used this, as he did further work on it within IcedTea, and I believe it may be enabled in Debian and/or Ubuntu builds. It’s also available (via USE=”nss”) in Gentoo, and it all three distros, it can be used to make elliptic curve cryptography available; this was the original motivation for adding support as noted in PR356.

Over the last week or so, we at Red Hat have been looking at whether using this NSS provider as the primary provider (i.e. listing it as number one in the file) provides a performance advantage, specifically as concerns AES and the fact that newer chips have AES instructions which are supported by assembly code in NSS. We wrote a little test case which runs a number of encryption and decryption cycles (we ran with 20,000) and measures the average number of nanoseconds take to encrypt or decrypt each byte, and the amount of MB/s overall. We ran this on both IcedTea6 & IcedTea7 builds with and without the NSS provider enabled at the top priority. The results are below. The ns/byte figures are rounded to two decimal places. Tests were run on a 2.7GHz Intel Xeon E5-2680 machine with hardware AES instructions and 4 processors with 8 cores each, giving 32 cores, each with 20MB L3 cache.

IcedTea6 without the NSS provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 9.54 ns/byte, 99MB/s 10.57 ns/byte, 90MB/s 9.10 ns/byte, 105MB/s 9.80 ns/byte, 97MB/s 8.77 ns/byte, 108MB/s 9.35 ns/byte, 102MB/s 8.70 ns/byte, 109MB/s 9.43 ns/byte, 101MB/s
192 bit 10.42 ns/byte, 91MB/s 11.29 ns/byte, 84MB/s 10.66 ns/byte, 89MB/s 11.48 ns/byte, 83MB/s 9.95 ns/byte, 96MB/s 10.67 ns/byte, 89MB/s 10.23 ns/byte, 93MB/s 10.75 ns/byte, 88MB/s
256 bit 11.80 ns/byte, 80MB/s 12.79 ns/byte, 74MB/s 12.03 ns/byte, 79MB/s 12.98 ns/byte, 73MB/s 11.17 ns/byte, 85MB/s 11.96 ns/byte, 80MB/s 11.08 ns/byte, 86MB/s 12.00 ns/byte, 79MB/s

IcedTea6 with the NSS Provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 2.77 ns/byte, 344MB/s 1.16 ns/byte, 832MB/s 1.70 ns/byte, 571MB/s 0.44 ns/byte, 2222MB/s 1.99 ns/byte, 487MB/s 0.77 ns/byte, 1250MB/s 2.17 ns/byte, 444MB/s 1.01 ns/byte, 952MB/s
192 bit 2.66 ns/byte, 363MB/s 0.92 ns/byte, 1050MB/s 2.07 ns/byte, 476MB/s 0.51 ns/byte, 2000MB/s 2.28 ns/byte, 425MB/s 0.83 ns/byte, 1176MB/s 2.45 ns/byte, 392MB/s 1.05 ns/byte, 909MB/s
256 bit 2.97 ns/byte, 322MB/s 0.99 ns/byte, 998MB/s 2.30 ns/byte, 416MB/s 0.57 ns/byte, 1818MB/s 2.57 ns/byte, 377MB/s 0.88 ns/byte, 1111MB/s 2.75 ns/byte, 350MB/s 1.11 ns/byte, 869MB/s

There’s clearly a significant improvement when using the NSS provider on a machine with AES instructions. We still need to run more tests to see what the improvement (if any) is when using NSS without AES instructions. As an aside, an early version of the test didn’t show as significant an increase, instead more like a 1.6x speedup. We believe this was down to several issues:

  1. The entire process was being measured, including setup of the cipher, not just the encryption.
  2. The use of System.currentTimeMillis() rather than nanoseconds
  3. The use of doFinal where it returns a new array, rather than reusing the old one, thus creating significant garbage.


Further results are collected in subsequent blogs: