Differences between revisions 7 and 8
Revision 7 as of 2012-05-16 14:25:52
Size: 5324
Editor: james-page
Revision 8 as of 2012-05-16 14:27:26
Size: 5324
Editor: james-page
Deletions are marked like this. Additions are marked like this.
Line 93: Line 93:
=== Maven2 ==- === Maven2 ===


As part of the Ubuntu Quantal Quetzal release cycle, the Ubuntu archive will be transitioned from OpenJDK6 to OpenJDK7.

Default Java (i.e the default-jdk et al packages) will provide OpenJDK7 instead of OpenJDK6 from opening of the archive.

Trouble Shooting FTBFS


FTBFS issues are likely to be the main focus of work during this transition. This is due to the fact that new version of Java are backwards binary compatible, i.e. you can run code built on Java 6 on a Java 7 runtime, but not backwards source compatible.

Hence any API or language changes in Java 7 will cause issues when re-compiling from source.

The other issue is consider is that code built with default flags on OpenJDK7 will not be compatible with older version of Java UNLESS a source/target version is provided. Maven does this by default but ant and javahelper packages may need nudging in the right way.

This type of issue looks like this:

java.lang.UnsupportedClassVersionError: [CLASSNAME] : Unsupported major.minor version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(

As OpenJDK6 will be retained in the archive for 12.10 (albeit in universe) backwards compatibility is still important. A lintian check to detect this is in progress.


error: unmappable character for encoding ASCII.

This issue constitutes that largest number of build failures; Java 7 treats source file encoding issues as errors rather than warnings - this can effect both javac and javadoc operations.



Ensure appropriate encoding is passed to javac and javadoc commands; this will normally need to be patched into the build.xml file:

<javac ...  encoding="ISO-8859-1">...

OR the source and target can be set explicitly for all javac and javadoc commands using:

# Ensure that source and target are 1.5
# For backwards compat on Java 7


Defaults to source/target 1.5.

specify the source file encoding in debian/ (when in use) using:

# Set encoding for compatibilty with Java 7


Override/update debian/rules to specify source/target 1.5

    jh_build --javacopts="-source 1.5 -target 1.5" --javadoc-opts="-source 1.5"

Public API Changes

Package does not implement new public API requirements for Java 7; normally something JDBC related and relatively easy to fix.

Language Handling Changes

Some sort of language handling change (typically generics handling) causes the build failure e.g:

error: name clash: boxedFor(Class<? extends Boxed>,long) in
org.gnome.gdk.Plumbing and boxedFor(Class<?>,long) in
org.gnome.glib.Plumbing have the same erasure, yet neither hides the other

Again needs fixing upstream - I suspect that these again will follow specific patterns with stock fixes.


Maven 2 not parsing warning error message causing failure

could not parse error message: warning: [options] bootstrap class path not set in conjunction with -source 1.5

Bug in Maven 2; needs to handle new Java 7 warning message (see for explanation of what it means)

Private API

Package makes use of private API no longer present or changed in Java 7; harder to fix as requires use of different API or significant refactoring; best worked out with upstream.


Problems with JAVA_HOME in rules not matching default-java i.e. using openjdk6 explicitly, fixable in packaging

Test Failures

Failure in test suite caused build failure.

Fop/Font Handling

[exec] org.apache.fop.apps.FOPException: Can't load standard profile:

I think this is related to in openjdk-6

JavaTeam/Java7Default (last edited 2012-07-29 22:05:54 by ceefour)