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 general.
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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
