Are javac -target and -source arguments broken in JDK 1.5 ?

[Dean Schulze]

I've been compiling a J2EE application using JDK 1.5.0_04 for several
months now for deployment on a server that uses JDK 1.4. I've always
used the javac -target and -source arguments set to "1.4" (without the
quotes). To my horror I've just discovered that these settings allow
the use of JDK 1.5 features, specifically String.contains().

I compile this application with both Ant and Eclipse with the target and
source settings set to 1.4 and it never complains about the
String.contains().

Are the -target and -source arguments broken in JDK 1.5?

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I compile this application with both Ant and Eclipse with the target and
source settings set to 1.4 and it never complains about the
String.contains().

Are the -target and -source arguments broken in JDK 1.5?

No, they just don't do what one would expect them to do. They will
disallow syntax that isn't supported in JDK 1.4, but they will allow you
to use objects and methods that weren't defined in JDK 1.4. In order to
prevent this you will have to compile with a different rt.jar (?) in your
bootclasspath, the one from JDK 1.4.


javac -source 1.4 -target 1.4 -bootclasspath /path/to/jre1.4/lib/rt.jar


This should do it.

(Disclaimer: I haven't tried it.)

- --
Kenneth P. Turvey <[email protected]>
Phone : (314) 255-2199

XMPP IM: (e-mail address removed)
Yahoo IM: kpturvey2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEAozwi2ZgbrTULjoRAm4lAJ9Ad/bTEc15sm8b7xu6c3wB5NS2HgCglNY3
MBT4IAfvfr4sNuxKgo/Trd4=
=t+j2
-----END PGP SIGNATURE-----

 

[John C. Bollinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




No, they just don't do what one would expect them to do.

They do exactly what I would expect them to do, and also exactly what
they are documented to do. How is the compiler supposed to know which
methods in platform library were introduced in which version of the JDK?
Yes, it could be made to know, but the initial and continuing costs
would be enormous, and the benefit by no means proportional.
Furthermore, the compiler's behavior is thoroughly analogous to the
behavior of previous versions in this area.

-target is about class file format and features
-source is about language syntax
-bootclasspath is about system class definitions for checking linking

I'll grant that this combination of options doesn't do what one might
naively hope it would, but a hope is a long way from a well-founded
expectation.

They will
disallow syntax that isn't supported in JDK 1.4, but they will allow you
to use objects and methods that weren't defined in JDK 1.4. In order to
prevent this you will have to compile with a different rt.jar (?) in your
bootclasspath, the one from JDK 1.4.


javac -source 1.4 -target 1.4 -bootclasspath /path/to/jre1.4/lib/rt.jar


This should do it.

(Disclaimer: I haven't tried it.)

I haven't tried it with 1.5, but the analogous approach works to get the
1.4 compiler to generate classes for 1.3.

 

[Chris Uppal]

How is the compiler supposed to know which
methods in platform library were introduced in which version of the JDK?
Yes, it could be made to know, but the initial and continuing costs
would be enormous, and the benefit by no means proportional.

Especially when there's already an effective, and widely used, technique for
compiling source so that it only uses 1.x platform features -- use a 1.x JDK...

-- chris

 

[Thomas Hawtin]

Especially when there's already an effective, and widely used, technique for
compiling source so that it only uses 1.x platform features -- use a 1.x JDK...

If you want to deal with all the unfixed compiler bugs as well as the
JRE bugs. The amount of critical time I wasted on the 1.1 javac
producing illegal code was not amusing. OTOH, the 1.4 -> 1.5 jump seems
to have reduced the stability of the compiler (although the majority of
bugs appear to be -source 1.5 only).

Tom Hawtin

 

[Chris Uppal]

Thomas Hawtin wrote:

[me:]

If you want to deal with all the unfixed compiler bugs as well as the
JRE bugs. The amount of critical time I wasted on the 1.1 javac
producing illegal code was not amusing.

If you are going far enough back in time for compiler stability to be a worry,
then you could use the 1.x JDK as a checking tool. You build with it from time
to time, but discard the resulting bytecode.

-- chris

 

[Roedy Green]

They do exactly what I would expect them to do, and also exactly what
they are documented to do. How is the compiler supposed to know which
methods in platform library were introduced in which version of the JDK?

see http://mindprod.com/projects/jdkversion.html

 

[Thomas Hawtin]

If you are going far enough back in time for compiler stability to be a worry,
then you could use the 1.x JDK as a checking tool. You build with it from time
to time, but discard the resulting bytecode.

Instead of -bootclasspath? You still need to use -bootclasspath even if
the code does compile on earlier versions. For instance, appending a
StringBuffer to a StringBuffer is valid on all versions of Java
(possibly not JavaCard). However, class files compiled with 1.4 will use
StringBuffer.append(StringBuffer) which does not exist in 1.3.

Tom Hawtin