November 2010


We are pleased to announce a new set of security releases, IcedTea6 1.7.6, IcedTea6 1.8.3 and IcedTea6 1.9.2.

This update contains the following security updates:

The IcedTea project provides a harness to build the source code from OpenJDK6 using Free Software build tools. It also includes the only Free Java plugin and Web Start implementation, and support for additional architectures over and above x86, x86_64 and SPARC via the Zero assembler port.

What’s New?

IcedTea6 1.7.6

  • Allow the building of NetX to be disabled.
  • Security updates
  • Backports
    • S6853592: VM test nsk.regression.b4261880 fails with “X Error of failed request: BadWindow” inconsistently.
  • NetX
    • Do not prompt user multiple times for the same certificate.
    • PR592: NetX can create invalid desktop entry files

IcedTea6 1.8.3

  • Allow the building of NetX to be disabled.
  • Security updates
  • Backports
    • S6853592: VM test nsk.regression.b4261880 fails with “X Error of failed request: BadWindow” inconsistently.
  • NetX
    • Do not prompt user multiple times for the same certificate.
    • PR592: NetX can create invalid desktop entry files

IcedTea6 1.9.2

  • Upgrade to latest revision of hs19 (b09).
  • Allow the building of NetX to be disabled.
  • Additional S390 size_t fixes.
  • Switch to the IcedTea server for JAXP, JAF and JAXWS tarballs.
  • Security updates
  • Backports
    • S6622432: RFE: Performance improvements to java.math.BigDecimal
    • S6850606: Regression from JDK 1.6.0_12
    • S6876282: BigDecimal’s divide(BigDecimal bd, RoundingFormat r) produces incorrect result
    • S6991430, PR579: Zero PowerPC fix.
    • S6703377: freetype: glyph vector outline is not translated correctly
    • S6853592: VM test nsk.regression.b4261880 fails with “X Error of failed request: BadWindow” inconsistently.
  • Bug fixes
    • RH647737: Disable compressed oops in hs19 to avoid Eclipse failures.
    • RH643674: Update fontconfig files for Fedora 11, 12, 13 and 14.
  • NetX
    • Do not prompt user multiple times for the same certificate.
    • PR592: NetX can create invalid desktop entry files

The tarballs can be downloaded from:

SHA256 sums

  • b28c8bd39d9bd8a28efaaa38280288a3faa6bec0d756323c0555ad3d8c5d77f5 icedtea6-1.7.6.tar.gz
  • d65a16345e8f6a702e5db1efbe02d0c41b565d4d1afce2d011169588fe8aa6ad icedtea6-1.8.3.tar.gz
  • abed4d2258fd6f047b08926fa9dbde86bdf7f47b08c82c195abb7244163cf99b icedtea6-1.9.2.tar.gz

The following people helped with these releases:

  • Deepak Bhole
  • Dan Horák
  • Andrew John Hughes
  • Matthias Klose
  • Omair Majid
  • Pavel Tisnovsky
  • Jiri Vanek

We would also like to thank the bug reporters and testers!

To get started:

$ tar xzf icedtea6-.tar.gz
$ cd icedtea6-

Full build requirements and instructions are in INSTALL:

$ ./configure [--enable-zero --enable-pulse-java --enable-systemtap ...]
$ make

Join us at FOSDEM 2011 to be a part of our sessions where we’ll discuss the state of Free Java!

Our theme is “Java Sans Frontières”

  • Why Free Java technology is awesome
  • Standing on the Shoulders of Free Java
  • The future of Free Java

The Call For Participation is OPEN NOW, but closes on 3rd December…
So send in a talk proposal today and join us in Brussels 5-6 February!

Why FOSDEM?

  • Engage in scintillating discussions with smart hackers over world famous Belgian Beer
  • Join the Web of Trust by getting your strong new key signed
  • Indulge in exquisite chocolate
  • Visit historic Brussels within walking distance

Why the Free Java DevJam?

  • This is the most significant non-commercial, neutral environment for Java developers to meet
  • Learn how to get involved in technical Free Java projects
  • We will not shy away from politics (especially this year)!
  • We will get together for an awesome dinner!
  • You will meet historic hackers in the evolution of Free Java

Please join the freejava-devroom@lists.fosdem.org list for general discussion about the event.

To submit a formal Talk Proposal follow the guidelines at
http://wiki.debian.org/Java/DevJam/2011/Fosdem/CallForParticipation

Respectfully,

In developing GNU Classpath, one problem that was commonly encountered was that applications would assume that the user was running on the proprietary Sun (now Oracle) JDK. This would enter into the code as the use of internal sun.* and com.sun.* APIs. So, even if all the standard APIs were provided by GNU Classpath, with all specified and unspecified behaviour, these applications would still fail because some undocumented proprietary API was being used.

My guess would be that Apache Harmony has also hit this problem. Certainly it seems it even occurred to developers of javac, as such usage presents a warning:

PluginAppletViewer.java:1516: warning: sun.applet.AppletPanel is internal
proprietary API and may be removed in a future release
    p.sendEvent(AppletPanel.APPLET_DESTROY);

I suspect they did this for a different reason; having external code depending on these APIs means that changes cause complaints from external developers and this warning seems to act as a way of absolving the JDK developers of responsibility for such breakage. Releases of JDK6 are already restricted into keeping the specified API the same. Restricting internal APIs as well would make the appearance of new features like Nimbus midway through the JDK6 release cycle impossible.

The reason I raise this issue now is that the danger of such usage seems to be increasing. Development of GNU Classpath and its associated JDKs has dropped significantly since the appearance of OpenJDK, and now that IBM have left Harmony for OpenJDK, development there is also likely to plummet.

This drop in diversity in the JDK space leads to an increasing dependence on one defacto JDK (OpenJDK) and the concomitant assumptions that users will be using this and so there is no reason not to use internal APIs or test on other solutions. I guess some people will see this as beneficial. It’s not. Having a standard API is beneficial. Having everyone reliant on one implementation of that API discourages good specification of that API.

We already have a situation where the TCK has only been run successfully against class libraries derived from the Sun/Oracle implementation (Harmony and GNU Classpath have never been able to license it under acceptable terms) and so there’s no assurance that it doesn’t depend on peculiarities specific to that implementation. It seems these recent developments in the JDK space will only see more homogenisation and further lower the likelihood that there will ever be an alternative clean-room implementation of the JDK.