Cross-Compile to V1.4 compatible with Java 5 javac

Hi group

At
http://java.sun.com/j2se/1.5.0/docs/...sscomp-example

there is a cross-compilation example:

% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip \
-extdirs "" OldCode.java

.... for compiling down to 1.4 compatibility with Java 5's javac.

I've inspected my 1.4 J2SDK and cannot find a classes.zip file
anywhere. The description indicates that it's necessary for the javac
invocation to specify the JDK 1.4 bootstrap classes for the compilate
to reliably be 1.4 compatible.

Apart from not finding the bootstrap classes in my 1.4 installation, I
need to be able to write some (scripting) code to do the
downcompilation on machines that ONLY have JDK 5 installed, so ideally
I don't want to include lots of big 1.4 files with my script.

Any ideas?

Lukas

"Lukas" <> wrote in
news: oups.com:

> Hi group
>
> At
> http://java.sun.com/j2se/1.5.0/docs/...c.html#crossco
> mp-example
>
> there is a cross-compilation example:
>
> % javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip \
> -extdirs "" OldCode.java
>
> ... for compiling down to 1.4 compatibility with Java 5's javac.
>

Do you mean that it's possible to use JRE 5 specific features while beeing
able to run the bytecode on a 1.4 environment ?

Zouplaz

No, the code is V 1.4 source-compatible.
I want to write a script that will compile code (autogenerated from an
application) on some arbitrary user's machine, which may only have JDK
5 installed, and the script will have to ensure that the resulting
classfiles are 1.4 binary compatible as they will be used from a
classloader in an application that was compiled under V1.4 .
Whew.
I originally thought it would be sufficient to use javac -target 1.4
but the article I linked to seems to indicate otherwise, if I
understand it correctly.

Lukas

Lukas <> wrote:
> No, the code is V 1.4 source-compatible.
> I want to write a script that will compile code (autogenerated from an
> application) on some arbitrary user's machine, which may only have JDK
> 5 installed, and the script will have to ensure that the resulting
> classfiles are 1.4 binary compatible as they will be used from a
> classloader in an application that was compiled under V1.4 .
> Whew.
> I originally thought it would be sufficient to use javac -target 1.4
> but the article I linked to seems to indicate otherwise, if I
> understand it correctly.

If you're certain that the code is valid on Java 1.4, then it should be
sufficient to use "javac -target 1.4". If you want to be ultra-correct,
you can use "javac -source 1.4 -target 1.4" instead, which will also
prevent the compiler from interpreting the source code as Java 1.5.

If you need compile-time type checking against the Java 1.4 API, though,
then things get trickier. In that case, you will NEED to obtain a copy
of the standard API classes from a Java 1.4 JRE or JDK. The Sun example
is misleading... this will be the "rt.jar" file, not "classes.zip". The
name used in the Sun example is from older Java versions (1.1 and
earlier, IIRC). Note that this is ONLY necessary in order to get the
compiler to check code against the 1.4 API... for example, it is
required for the compiler to be able to give an error message is someone
accidentally uses new 1.5 API calls in the code.

So, you should look at these options:

-target (controls output bytecode format)
-source (controls syntactic interpretation of source)
-bootclasspath (controls the API classes to check/link with)

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith

Hi Chris,

that totally clears it up. For my purposes it will then be sufficient
to run "javac -source 1.4 -target 1.4" .

Thanks !!

Lukas

Lukas

Chris Smith wrote:
>
> If you're certain that the code is valid on Java 1.4, then it should be
> sufficient to use "javac -target 1.4". If you want to be ultra-correct,
> you can use "javac -source 1.4 -target 1.4" instead, which will also
> prevent the compiler from interpreting the source code as Java 1.5.

On 5.0, you must specify -source 1.4 (or earlier) if you specify -target
1.4. Otherwise you'll get told off:

javac: target release 1.4 conflicts with default source release 1.5

> If you need compile-time type checking against the Java 1.4 API, though,
> then things get trickier. In that case, you will NEED to obtain a copy
> of the standard API classes from a Java 1.4 JRE or JDK. The Sun example
> is misleading... this will be the "rt.jar" file, not "classes.zip". The
> name used in the Sun example is from older Java versions (1.1 and
> earlier, IIRC). Note that this is ONLY necessary in order to get the
> compiler to check code against the 1.4 API... for example, it is
> required for the compiler to be able to give an error message is someone
> accidentally uses new 1.5 API calls in the code.

For some valid older code -bootclasspath/-Xbootclasspath: may be
necessary as newer versions may add overloaded methods, which will be
picked up preferentially.

For instance, 1.4 added StringBuffer.append(StringBuffer). Old source
code expecting to use StringBuffer.append(Object) would pick up the new
method and so not be runnable under 1.3.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

Thomas Hawtin

On 20 Sep 2005 03:40:47 -0700, "Lukas" <> wrote or
quoted :

> jdk1.4.2/lib/classes.zip

rt.jar contains most of the classes.

There are others;
8,510,924 charsets.jar
1,900,211 deploy.jar
757,681 javaws.jar
81,799 jce.jar
493,381 jsse.jar
997,206 plugin.jar
33,725,045 rt.jar
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green

On 20 Sep 2005 07:59:48 -0700, "Lukas" <> wrote or
quoted :

>I originally thought it would be sufficient to use javac -target 1.4
>but the article I linked to seems to indicate otherwise, if I
>understand it correctly.

the big problem with just using target is it uses the 1.5 lib. So for
example I got in trouble using target -1.4 with
Component.setMaximumSize. I did not find out until somebody ran the
code under an earlier JVM that there was no such method back then.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green