Non-ASCII characters and OpenJDK

[gnu_andrew]

I came across an interesting build failure today with b68.  It seems
that the compiler decided to start enforcing -encoding ascii more
strongly (at least, I see no change to add this option, so maybe it is
a side-effect of moving to source = 1.7) and thus choked on a couple
of characters in the Xrender patches IcedTea applies (an umlaut and a
degree symbol).

Anyone know why this is suddenly enforced?  And why is it ascii rather
than utf8?
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Joe Darcy]

On 08/07/09 01:52 PM, Andrew John Hughes wrote:

> I came across an interesting build failure today with b68.  It seems
> that the compiler decided to start enforcing -encoding ascii more
> strongly (at least, I see no change to add this option, so maybe it is
> a side-effect of moving to source = 1.7) and thus choked on a couple
> of characters in the Xrender patches IcedTea applies (an umlaut and a
> degree symbol).
>
> Anyone know why this is suddenly enforced?  And why is it ascii rather
> than utf8?
>  

The fix for 6827026  "Change javac source and target default to 7" added
explicit -source options throughout the JDK build so keep the same build
semantics of -source 1.5.  As documented in the javac man page and as I
wrote up recently,

"As an operational difference [between -source 1.5 and -source 1.6],
|javac| handles encoding problems differently under those two source
levels; an encoding problem generates a warning with source 1.5 but is
treated as an error with source 1.6."
http://blogs.sun.com/darcy/entry/source_target_class_file_version

Therefore, after the fix for 6854244 "change source/target used to
compile JDK to 7," encoding problems are treated as errors since a
source setting greater than 1.6 is being used.

One solution to this problem is to set an explicit encoding for the compile:
http://blogs.sun.com/darcy/entry/build_advice_set_source_target

If an explicit encoding is not set, the platform default is used.

-Joe

[Mark Wielaard]

Hi,

On Fri, 2009-08-07 at 14:13 -0700, Joe Darcy wrote:
> The fix for 6827026  "Change javac source and target default to 7" added
> explicit -source options throughout the JDK build so keep the same build
> semantics of -source 1.5.  As documented in the javac man page and as I
> wrote up recently,

This, and the bump to b68, also seems to have broken the IcedTea7
bootstrap:
http://icedtea.classpath.org/pipermail/testresults/2009-August/000109.html
Note the "java.lang.ClassFormatError: CompilePropertiesTask
(unrecognized class file version)". I assume that is because some
-target output is used for a .class file too early in the bootstrap and
either the compiler or runtime used doesn't support it yet.

Cheers,

Mark

[jonathan.gibbons]

Mark,

The boot JDK must support Java 6 or better.  From the message in the  
previous
line about annotation processing, it would seem you're not using a  
version
of javac capable of compiling -source 6 files.

-- Jon

On Aug 10, 2009, at 3:41 AM, Mark Wielaard wrote:

> Hi,
>
> On Fri, 2009-08-07 at 14:13 -0700, Joe Darcy wrote:
>> The fix for 6827026  "Change javac source and target default to 7"  
>> added
>> explicit -source options throughout the JDK build so keep the same  
>> build
>> semantics of -source 1.5.  As documented in the javac man page and  
>> as I
>> wrote up recently,
>
> This, and the bump to b68, also seems to have broken the IcedTea7
> bootstrap:
> http://icedtea.classpath.org/pipermail/testresults/2009-August/000109.html
> Note the "java.lang.ClassFormatError: CompilePropertiesTask
> (unrecognized class file version)". I assume that is because some
> -target output is used for a .class file too early in the bootstrap  
> and
> either the compiler or runtime used doesn't support it yet.
>
> Cheers,
>
> Mark
>

[gnu_andrew]

2009/8/10 Mark Wielaard <mark@...>:

> Hi,
>
> On Fri, 2009-08-07 at 14:13 -0700, Joe Darcy wrote:
>> The fix for 6827026  "Change javac source and target default to 7" added
>> explicit -source options throughout the JDK build so keep the same build
>> semantics of -source 1.5.  As documented in the javac man page and as I
>> wrote up recently,
>
> This, and the bump to b68, also seems to have broken the IcedTea7
> bootstrap:
> http://icedtea.classpath.org/pipermail/testresults/2009-August/000109.html
> Note the "java.lang.ClassFormatError: CompilePropertiesTask
> (unrecognized class file version)". I assume that is because some
> -target output is used for a .class file too early in the bootstrap and
> either the compiler or runtime used doesn't support it yet.
>
> Cheers,
>
> Mark
>
>

I'll take a look when I'm back at work next week.

It goes without saying that it (eventually) worked for me or I
wouldn't have committed the change. Unfortunately, ant is about as
useful as a chocolate teapot when it comes to debugging such errors,
but I'd suggest taking a look at which JDK is running ant.  I've had
all manner of JDKs end up running it before, including kaffe once
which caused some rather bizarre results!
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Mark Wielaard]

[sorry if this becomes a duplicate, I sent the original from an
unsubscribed address to the list, hopefully resending from the address
actually subscribed to the list now.]

Hi Jon,

On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote:
> The boot JDK must support Java 6 or better.  From the message in the  
> previous line about annotation processing, it would seem you're not using a  
> version of javac capable of compiling -source 6 files.

Although IcedTea can indeed also try to bootstrap things with 1.5
capable tools (most of this is now disabled in IcedTea7 I see) I don't
think that was the issue in this case. It might be related though.

IcedTea goes out of its way to try to make openjdk "bootstrappable"
through the existing GNU java toolchains. So maybe some of the effort of
tuning the -target and -source for the new 1.7 source/target have been
biting each other. This might be more visible with IcedTea because the
existing GNU java toolchain isn't monolithic like the openjdk one, so
the core libraries, runtime vm and/or the compiler might have different
source/target defaults and coverage.

The CompilePropertiesTask that the original error was about had a class
major version of 51, which indicates it was generated through -target
1.7 (or at least some compiler defaulting to 1.7). But since that class
is used in the bootstrap cycle I think it should explicitly target 1.6.

So I think this part in langtools/make/build.xml needs an explicit
source="${boot.javac.source}" and target="${boot.javac.target}":

        <javac fork="true"
               executable="${boot.java.home}/bin/javac"
               srcdir="${make.tools.dir}/CompileProperties"
               destdir="${build.toolclasses.dir}/"
               classpath="${ant.home}/lib/ant.jar"/>

The same thing happens later in the build with some other classes that
are compiled and then run using the bootstrap tools.

The corba stripproperties classes. The BOOT_JAVAC_CMD in
corba/make/common/BuildToolJar.gmk doesn't define a source or target,
they should probably be defined in as BOOT_CLASS_VERSION in
corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
since these classes will be run during the build on the bootstrap
runtime vm.

Similarly for the hotspot gamma classes. They are compiled with
COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
should probably also include an explicit target/source setting.
Similarly for the jvmtiGen classes that are run using the bootstrap
runtime vm.

Especially the jdk build is a bit tricky since some things like the
generatebreakiteratordata and javazic tools that are run during the
build to generate classes and/or new source/property files combine
classes that will go into the new rt.jar, and so have been compiled with
-target 1.7, with tools build classes (like sun.text or
sun.util.calendar classes) which have been compiled with -target 1.6,
and that should be run by the bootstrap jdk (which is only capable of
understanding 1.6 classes). This can be solved by making a copy of those
classes and putting them in to tool package so the whole tool is 1.6
runnable, but this is slightly ugly because that means you build stuff
twice (once for -target 1.6 to run the tool and once for -target 1.7 to
put into rt.jar).

I'll try to go through a whole build (currently stuck on the bootstrap
rmic not liking to generate Stub classes for some of the new-target 1.7
classes) and suggest some real patches. That is after I made sure it
isn't caused by some of the IcedTea "cleanup" patches that already try
to do the same thing. And if any of the above sounds terribly wrong,
please do yell and shout, so I take another step back.

Thanks,

Mark

[jonathan.gibbons]

On Aug 12, 2009, at 3:35 PM, Mark Wielaard wrote:

> Hi Jon,
>
> On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote:
>> The boot JDK must support Java 6 or better.  From the message in the
>> previous line about annotation processing, it would seem you're not  
>> using a
>> version of javac capable of compiling -source 6 files.
>
> Although IcedTea can indeed also try to bootstrap things with 1.5
> capable tools (most of this is now disabled in IcedTea7 I see) I don't
> think that was the issue in this case. It might be related though.
>
> IcedTea goes out of its way to try to make openjdk "bootstrappable"
> through the existing GNU java toolchains. So maybe some of the  
> effort of
> tuning the -target and -source for the new 1.7 source/target have been
> biting each other. This might be more visible with IcedTea because the
> existing GNU java toolchain isn't monolithic like the openjdk one, so
> the core libraries, runtime vm and/or the compiler might have  
> different
> source/target defaults and coverage.
>
> The CompilePropertiesTask that the original error was about had a  
> class
> major version of 51, which indicates it was generated through -target
> 1.7 (or at least some compiler defaulting to 1.7). But since that  
> class
> is used in the bootstrap cycle I think it should explicitly target  
> 1.6.
>
> So I think this part in langtools/make/build.xml needs an explicit
> source="${boot.javac.source}" and target="${boot.javac.target}":
>
>        <javac fork="true"
>               executable="${boot.java.home}/bin/javac"
>               srcdir="${make.tools.dir}/CompileProperties"
>               destdir="${build.toolclasses.dir}/"
>               classpath="${ant.home}/lib/ant.jar"/>
>
> The same thing happens later in the build with some other classes that
> are compiled and then run using the bootstrap tools.

While it would not be wrong to specify boot.javac.source and  
boot.java.target
it should not be necessary if it is compiled and run with equivalent  
versions of
javac and java from the same ${boot.java.home}.

>
>
> The corba stripproperties classes. The BOOT_JAVAC_CMD in
> corba/make/common/BuildToolJar.gmk doesn't define a source or target,
> they should probably be defined in as BOOT_CLASS_VERSION in
> corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
> since these classes will be run during the build on the bootstrap
> runtime vm.
>
> Similarly for the hotspot gamma classes. They are compiled with
> COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
> could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
> should probably also include an explicit target/source setting.
> Similarly for the jvmtiGen classes that are run using the bootstrap
> runtime vm.
>
> Especially the jdk build is a bit tricky since some things like the
> generatebreakiteratordata and javazic tools that are run during the
> build to generate classes and/or new source/property files combine
> classes that will go into the new rt.jar, and so have been compiled  
> with
> -target 1.7, with tools build classes (like sun.text or
> sun.util.calendar classes) which have been compiled with -target 1.6,
> and that should be run by the bootstrap jdk (which is only capable of
> understanding 1.6 classes). This can be solved by making a copy of  
> those
> classes and putting them in to tool package so the whole tool is 1.6
> runnable, but this is slightly ugly because that means you build stuff
> twice (once for -target 1.6 to run the tool and once for -target 1.7  
> to
> put into rt.jar).
>
> I'll try to go through a whole build (currently stuck on the bootstrap
> rmic not liking to generate Stub classes for some of the new-target  
> 1.7
> classes) and suggest some real patches. That is after I made sure it
> isn't caused by some of the IcedTea "cleanup" patches that already try
> to do the same thing. And if any of the above sounds terribly wrong,
> please do yell and shout, so I take another step back.
>
> Thanks,
>
> Mark
>

[jonathan.gibbons]

On Aug 12, 2009, at 5:03 PM, Jonathan Gibbons wrote:

>
> On Aug 12, 2009, at 3:35 PM, Mark Wielaard wrote:
>
>> Hi Jon,
>>
[snip]

>>
>> So I think this part in langtools/make/build.xml needs an explicit
>> source="${boot.javac.source}" and target="${boot.javac.target}":
>>
>>       <javac fork="true"
>>              executable="${boot.java.home}/bin/javac"
>>              srcdir="${make.tools.dir}/CompileProperties"
>>              destdir="${build.toolclasses.dir}/"
>>              classpath="${ant.home}/lib/ant.jar"/>
>>
>> The same thing happens later in the build with some other classes  
>> that
>> are compiled and then run using the bootstrap tools.
>
>
> While it would not be wrong to specify boot.javac.source and  
> boot.java.target
> it should not be necessary if it is compiled and run with equivalent  
> versions of
> javac and java from the same ${boot.java.home}.
>

I take that back. I agree that source and target values should be  
specified here,
since the class is compiled with boot.java but executed by Ant.   I  
have some
other minor fixes for build.xml underway, and will include this fix as  
well.

> [snip]

-- Jon

[gnu_andrew]

2009/8/12 Mark Wielaard <mark@...>:

> [sorry if this becomes a duplicate, I sent the original from an
> unsubscribed address to the list, hopefully resending from the address
> actually subscribed to the list now.]
>
> Hi Jon,
>
> On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote:
>> The boot JDK must support Java 6 or better.  From the message in the
>> previous line about annotation processing, it would seem you're not using a
>> version of javac capable of compiling -source 6 files.
>

It's been possible to bootstrap OpenJDK with the GNU toolchain since
June 2007 (with a few workarounds) and that setup has certainly been
capable of compiling 1.6 source files.  Given, AFAIK, the only changes
between 1.5 and 1.6 were verifier changes, I don't see why it would be
a problem.  Without being able to do this, there wouldn't be an
IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
distributions.

> Although IcedTea can indeed also try to bootstrap things with 1.5
> capable tools (most of this is now disabled in IcedTea7 I see)

What has been disabled?  I still run every new IcedTea7 build with
gcj.  Nothing has changed AFAIK.

 I don't

> think that was the issue in this case. It might be related though.
>
> IcedTea goes out of its way to try to make openjdk "bootstrappable"
> through the existing GNU java toolchains. So maybe some of the effort of
> tuning the -target and -source for the new 1.7 source/target have been
> biting each other. This might be more visible with IcedTea because the
> existing GNU java toolchain isn't monolithic like the openjdk one, so
> the core libraries, runtime vm and/or the compiler might have different
> source/target defaults and coverage.
>

The javac.in script did have to be changed to pass -1.7 instead of 1.5
to build with this latest version (this applies to ecj only).  After
that, it worked AFAIR.  You could try reverting this and see if it
helps.  It's also worth checking what is being used by Ant and what is
being used by bootstrap/ecj.
The problem is there is not one but three 'JDKs' in the mix here.
It's even more complicated if you consider each of them can be a mix
of different VMs and compilers.  Things would be easier to debug if
Ant wasn't being used.

> The CompilePropertiesTask that the original error was about had a class
> major version of 51, which indicates it was generated through -target
> 1.7 (or at least some compiler defaulting to 1.7). But since that class
> is used in the bootstrap cycle I think it should explicitly target 1.6.
>
> So I think this part in langtools/make/build.xml needs an explicit
> source="${boot.javac.source}" and target="${boot.javac.target}":
>
>        <javac fork="true"
>               executable="${boot.java.home}/bin/javac"
>               srcdir="${make.tools.dir}/CompileProperties"
>               destdir="${build.toolclasses.dir}/"
>               classpath="${ant.home}/lib/ant.jar"/>
>
> The same thing happens later in the build with some other classes that
> are compiled and then run using the bootstrap tools.
>
> The corba stripproperties classes. The BOOT_JAVAC_CMD in
> corba/make/common/BuildToolJar.gmk doesn't define a source or target,
> they should probably be defined in as BOOT_CLASS_VERSION in
> corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
> since these classes will be run during the build on the bootstrap
> runtime vm.
>
> Similarly for the hotspot gamma classes. They are compiled with
> COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
> could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
> should probably also include an explicit target/source setting.
> Similarly for the jvmtiGen classes that are run using the bootstrap
> runtime vm.
>
> Especially the jdk build is a bit tricky since some things like the
> generatebreakiteratordata and javazic tools that are run during the
> build to generate classes and/or new source/property files combine
> classes that will go into the new rt.jar, and so have been compiled with
> -target 1.7, with tools build classes (like sun.text or
> sun.util.calendar classes) which have been compiled with -target 1.6,
> and that should be run by the bootstrap jdk (which is only capable of
> understanding 1.6 classes). This can be solved by making a copy of those
> classes and putting them in to tool package so the whole tool is 1.6
> runnable, but this is slightly ugly because that means you build stuff
> twice (once for -target 1.6 to run the tool and once for -target 1.7 to
> put into rt.jar).
>
> I'll try to go through a whole build (currently stuck on the bootstrap
> rmic not liking to generate Stub classes for some of the new-target 1.7
> classes) and suggest some real patches. That is after I made sure it
> isn't caused by some of the IcedTea "cleanup" patches that already try
> to do the same thing. And if any of the above sounds terribly wrong,
> please do yell and shout, so I take another step back.
>
> Thanks,
>
> Mark
>
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Mark Wielaard]

Hi Andrew,

On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
> 2009/8/12 Mark Wielaard <mark@...>:
> It's been possible to bootstrap OpenJDK with the GNU toolchain since
> June 2007 (with a few workarounds) and that setup has certainly been
> capable of compiling 1.6 source files.  Given, AFAIK, the only changes
> between 1.5 and 1.6 were verifier changes, I don't see why it would be
> a problem.  Without being able to do this, there wouldn't be an
> IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
> distributions.

Precisely. Which brings us to...

> > Although IcedTea can indeed also try to bootstrap things with 1.5
> > capable tools (most of this is now disabled in IcedTea7 I see)
>
> What has been disabled?  I still run every new IcedTea7 build with
> gcj.  Nothing has changed AFAIK.

IcedTea (specifically patches/ecj/icedtea.patch) used to set explicit
-source/target 1.5 options. Mostly at the same points that now also have
such settings in openjdk7. So those have been removed to not conflict.
But they are now explicitly 1.6, no longer 1.5.

This isn't a problem with newer/patches gcj/gij, since those do accept
class major version 51 (even though it don't use the stack maps), but
older gcj/gij doesn't accept such major class versions. (As you point
out above, there is no real advantage using 1.6 over 1.5 in the VM. As
long as the class library supports the needed 1.6 classes - as gnu
classpath does.)

> The problem is there is not one but three 'JDKs' in the mix here.
> It's even more complicated if you consider each of them can be a mix
> of different VMs and compilers.  Things would be easier to debug if
> Ant wasn't being used.

Yes, ant makes things just that much more interesting... :}

I have slowly gone through the build to try to have the "tool
classes" (that need to be run during the build) and the "final rt
classes" (that don't need to be run during the build) have explicitly
compiled with the -source/target specifically set. Not fully there yet.

The biggest problem is the jdk build. There are a couple of tools that
are run during the build but that depend on com.sun.* classes that are
(also) compiled as part of the runtime rt classes.

This currently only work by accident. There are two slightly different
ways this can happen:
a) because you are using a bootstrap vm that already has those com.sun.*
classes on the bootclasspath (the wrong old version is used then, not
the just compiled one, but the one in the bootstrap vm core class
libraries).
b) because you use a bootstrap vm (like newer gcj/gij) that accepts a
mix of major class versions (1.6/50 for the tool classes and 1.7/51 for
the rt classes) when running the java build generation tools (this will
work until one of the accidentally included new rt classes will actually
start using invokedynamic, it already fails with gcj/gij that don't
accept such newer 1.7/41 classes - such as the gcj/gij on Debian
stable.).

Cheers,

Mark

[gnu_andrew]

2009/8/17 Mark Wielaard <mark@...>:

> Hi Andrew,
>
> On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
>> 2009/8/12 Mark Wielaard <mark@...>:
>> It's been possible to bootstrap OpenJDK with the GNU toolchain since
>> June 2007 (with a few workarounds) and that setup has certainly been
>> capable of compiling 1.6 source files.  Given, AFAIK, the only changes
>> between 1.5 and 1.6 were verifier changes, I don't see why it would be
>> a problem.  Without being able to do this, there wouldn't be an
>> IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
>> distributions.
>
> Precisely. Which brings us to...
>
>> > Although IcedTea can indeed also try to bootstrap things with 1.5
>> > capable tools (most of this is now disabled in IcedTea7 I see)
>>
>> What has been disabled?  I still run every new IcedTea7 build with
>> gcj.  Nothing has changed AFAIK.
>
> IcedTea (specifically patches/ecj/icedtea.patch) used to set explicit
> -source/target 1.5 options. Mostly at the same points that now also have
> such settings in openjdk7. So those have been removed to not conflict.
> But they are now explicitly 1.6, no longer 1.5.
>
> This isn't a problem with newer/patches gcj/gij, since those do accept
> class major version 51 (even though it don't use the stack maps), but
> older gcj/gij doesn't accept such major class versions. (As you point
> out above, there is no real advantage using 1.6 over 1.5 in the VM. As
> long as the class library supports the needed 1.6 classes - as gnu
> classpath does.)
>
>> The problem is there is not one but three 'JDKs' in the mix here.
>> It's even more complicated if you consider each of them can be a mix
>> of different VMs and compilers.  Things would be easier to debug if
>> Ant wasn't being used.
>
> Yes, ant makes things just that much more interesting... :}
>
> I have slowly gone through the build to try to have the "tool
> classes" (that need to be run during the build) and the "final rt
> classes" (that don't need to be run during the build) have explicitly
> compiled with the -source/target specifically set. Not fully there yet.
>
> The biggest problem is the jdk build. There are a couple of tools that
> are run during the build but that depend on com.sun.* classes that are
> (also) compiled as part of the runtime rt classes.
>
> This currently only work by accident. There are two slightly different
> ways this can happen:
> a) because you are using a bootstrap vm that already has those com.sun.*
> classes on the bootclasspath (the wrong old version is used then, not
> the just compiled one, but the one in the bootstrap vm core class
> libraries).
> b) because you use a bootstrap vm (like newer gcj/gij) that accepts a
> mix of major class versions (1.6/50 for the tool classes and 1.7/51 for
> the rt classes) when running the java build generation tools (this will
> work until one of the accidentally included new rt classes will actually
> start using invokedynamic, it already fails with gcj/gij that don't
> accept such newer 1.7/41 classes - such as the gcj/gij on Debian
> stable.).
>
> Cheers,
>
> Mark
>
>

After some experimentation:

* OpenJDK7 (from the IcedTea forest) builds fine on its own (i.e.
without IcedTea) using IcedTea6.  So we haven't picked the bug Martin
and I had on OpenJDK6.
* javac.in has always passed -1.5 to ecj as it defaults to 1.4.
Leaving this in causes langtools to fail in build-bootstrap-javac:

  [javac] Compliance level '1.5' is incompatible with source level
'1.6'. A compliance level '1.6' or better is required

* changing this to 1.6 causes a later failure in build.classes.javac

 [javac] Compliance level '1.6' is incompatible with source level
'1.7'. A compliance level '1.7' or better is required

* getting rid of it altogether allows langtools to build and breaks
corba which isn't setting source/target:

/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javac
-J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m -encoding ascii -d
/mnt/builder/icedtea7/openjdk-ecj/build/linux-amd64/corba/btclasses \
            -sourcepath ../../tools/src
../../tools/src/build/tools/stripproperties/StripProperties.java

This only works on IcedTea because it defaults to a higher
source/target version.

* using 1.7 in javac.in works for me, but clearly not for mjw.

So I think we need to remove the option and specify it explicitly when
needed.  Which means some more OpenJDK fixes are required.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8