ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: issues with ant
Date Wed, 10 Nov 2010 14:54:51 GMT
On 11/10/2010 12:17 AM, Stefan Bodewig wrote:
> The projects use a javac task like
>       <javac target="1.5">...</javac>
> which is translated to a command line
>        javac -target 1.5 ...
> This works fine with JDK6's javac but causes the error you've cited when
> run with OpenJDK 7.  This is not the first time this happens, the javac
> developers obviously don't care a bit for backwards compatibility.

The real problem is neither javac nor Ant, but the build script, which fails to specify source="...".
The source level defaults to the newest level supported by the 
compiler, now 1.7; and it may not be *possible* to compile 1.7 sources to 1.5 bytecode in

Specify source="1.5" and you should be fine.

>                  attributes.log("If you specify -target " + t
>                                 + " you now must also specify -source " + s
>                                 + ".", Project.MSG_WARN);
>                  attributes.log("Ant will implicitly add -source " + s
>                                 + " for you.  Please change your build file.",
>                                 Project.MSG_WARN);

And pay attention to warnings in the future.

> this really is javac's fault

There's not really any good alternative policy for javac when the user does not bother to
specify a source level. Perhaps the -source and -target parameters should have 
been mandatory from the very beginning, but they were not; and defaulting them to an old value
(how old? 1.0?) would be unintuitive and cumbersome for casual command-line 
usage. It is the responsibility of a project configuration to always specify these parameters,
and Ant is doing its best by issuing a warning if they are omitted.

BTW maven-compiler-plugin uses fixed defaults for source and target level, long 1.3 but now
1.5 in recent plugin releases. This is sensible enough given that it forces 
builds to be repeatable - a given default applies only to a given version of the plugin, which
at least as of Maven 3 is also required to be specified by the project. But 
then users have complained that it should use javac's defaults instead. A similar heated controversy
over platform default encoding vs. UTF-8 (when compiling, replacing 
tokens in text files, etc.) was put to a vote, with Japanese users in particular insisting
on using platform default encoding at the expense of build reproducibility - 
though the affected plugins do issue a warning if platform defaults are used.

> JDBC is changing in backwards incompatible ways again. [...]
> I haven't checked the new definition of Driver, let's hope it is
> possible to implement it in a way that also compiles on JDK 1.4

In general I have found that changes in JDBC, DOM, and some other APIs in the JRE often add
interfaces to methods under the assumption that this is breaking only to 
providers and not consumers. In general it is not possible to implement the new interfaces
while remaining compilable against the old APIs, since new methods often have 
signatures using newly introduced types. If you are implementing this kind of SPI just for
unit test mocks, your best bet is to use java.lang.reflect.Proxy. I can look at 
this particular case.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message