You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ludmila Shikhvarg <Lu...@oracle.com> on 2010/11/09 20:46:27 UTC
issues with ant
Hi,
I've discovered some ant's problem during gump testing with jdk7
1. The projects below failed to compile with jdk7 (1.7.0):
junit, test-junit
hamcrest, hamcrest-java, hamcrest-java-unit-test, hamcrest-java-all
args4j, args4j-tools, args4j-tests
tomcat-tc6, javax.el, javax.servlet, javax.servlet.jsp
ant-antlibs, antunit-test, dotnet-antlib-test, props-antlib-test,
svn-antlib-test, antunit, compress-antlib-test
commons-sandbox, commons-openpgp
ant-testutil, test-ant, test-ant-no-xerces
[javac] javac: target release 1.5 conflicts with default source release 1.7
Thought, there are should not be jdk dependency
2. Failed to run projects due to:
svn: URL 'http://svn.apache.org/repos/asf/ant/antlibs/ant-vss/trunk' doesn't exist
ant-antlibs project
vss-antlib
dotnet-antlib
compress-antlib
props-antlib
svn-antlib
3. All projects related to bootstrap-ant started to fail from jdk7 b112
with exception below:
compile-tests:
Created dir: /export/home/dtftest/gump/results/ant/build/testcases
Compiling 287 source files to /export/home/dtftest/gump/results/ant/build/testcases
/export/home/dtftest/gump/results/ant/src/tests/junit/org/apache/tools/ant/taskdefs/SQLExecTest.java:209: NullDriver is not abstract and does not override abstract method getParentLogger() in Driver
public static class NullDriver implements Driver {
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
BUILD FAILED
/export/home/dtftest/gump/results/ant/build.xml:983: The following error occurred while executing this line:
/export/home/dtftest/gump/results/ant/build.xml:1424: Compile failed; see the compiler error output for details.
Total time: 13 seconds
... Failed Building Ant Distribution !
bootstrap-ant
ant-testutil
dist-ant
jakarta-ant
test-ant
ant
org.apache.ant
test-ant-no-xerces
org.apache.dist-ant
Please let me know if you need additional information.
Thanks,
Ludmila
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: issues with ant
Posted by Jesse Glick <je...@oracle.com>.
On 11/11/2010 03:35 PM, Stefan Bodewig wrote:
> javac should do what Ant does for it in the Java5 case. If the
> user only specifies -target but not -source, assume the user wanted the
> same version as well (and vice versa).
Probably would be beneficial. I can file an issue for it in the Java bug tracker. But there may be compatibility issues with making a change like that, too.
> I wasn't complaining about JDBC breaking backwards compatibility - I
> understand it has to be done from time to time.
Well, they could have simply introduced Driver2 extends Driver for the new methods, and checked instanceof Driver2 before calling them. Fully compatible, simple, no need
for reflection (well technically instanceof + cast are reflective, but no java.lang.reflect.*). Too late.
>> your best bet is to use java.lang.reflect.Proxy.
>
> Never thought about that. Wouldn't that cause problems for performance
> critical implementations
Proxy shouldn't be too bad; a proxy class is generated when you create the proxy, so each method call just gets one indirection AFAIK. Method.invoke is a bit trickier -
it runs "interpreted" a few times, and then if you keep on calling it, does some bytecode generation to make an fast "inlined" method handle.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: issues with ant
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-11-10, Jesse Glick wrote:
> On 11/10/2010 12:17 AM, Stefan Bodewig wrote:
>> 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.
IMHO javac should do what Ant does for it in the Java5 case. If the
user only specifies -target but not -source, assume the user wanted the
same version as well (and vice versa). This would provide a better user
experience since you'd only have to specify both -source and -target if
you want them to be different.
>> 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.
Oh, I wasn't complaining about JDBC breaking backwards compatibility - I
understand it has to be done from time to time. If Ant's task API was
based on interfaces rather than reflection we would have broken it quite
a few times. And just looking at the ThreadLocal hacks in Zip that add
new features while maintaining the protected API I can understand that
breaking interfaces is the favored way of evolution.
It's just that quite a few projects of the Gump set won't build - like
those that provide database pools.
> If you are implementing this kind of SPI just for unit test mocks,
> your best bet is to use java.lang.reflect.Proxy.
Never thought about that. Wouldn't that cause problems for performance
critical implementations (I have a lot more experience with .NET's
reflection which has shown me that it doesn't have to be very slow but
it is certainly slower than direct method invocations)?
> I can look at this particular case.
Thank you.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: issues with ant
Posted by Jesse Glick <je...@oracle.com>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: issues with ant
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-11-09, Ludmila Shikhvarg wrote:
> I've discovered some ant's problem during gump testing with jdk7
Thank you for reporting them. It might be a good idea to open bugzilla
issues for them.
> 1. The projects below failed to compile with jdk7 (1.7.0):
> junit, test-junit
...
> [javac] javac: target release 1.5 conflicts with default source release 1.7
> Thought, there are should not be jdk dependency
This is not really Ant's fault. 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.
Ant's DefaultCompilerAdapter contains this code
} else if ((assumeJava15() || assumeJava16())
&& attributes.getTarget() != null) {
String t = attributes.getTarget();
if (t.equals("1.1") || t.equals("1.2") || t.equals("1.3")
|| t.equals("1.4")) {
String s = t;
if (t.equals("1.1")) {
// 1.5.0 doesn't support -source 1.1
s = "1.2";
}
attributes.log("", Project.MSG_WARN);
attributes.log(" WARNING", Project.MSG_WARN);
attributes.log("", Project.MSG_WARN);
attributes.log("The -source switch defaults to 1.5 in JDK 1.5 and 1.6.",
Project.MSG_WARN);
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);
cmd.createArgument().setValue("-source");
cmd.createArgument().setValue(s);
}
which implicitly adds a -source 1.2 when running on Java5 or Java6 and
the user specified the target attribute but not the source attribute.
We'd need similar code to adapt to the new default in OpenJDK7 and a
target different from 1.7.
Again, this really is javac's fault and Ant can only try to lessen the
impact.
> 2. Failed to run projects due to:
> svn: URL 'http://svn.apache.org/repos/asf/ant/antlibs/ant-vss/trunk' doesn't exist
Looks as if the svn:externals on
http://svn.apache.org/repos/asf/ant/antlibs/all-trunks is wrong, I'll
look into it. Thank you for reporting.
> 3. All projects related to bootstrap-ant started to fail from jdk7
> b112 with exception below:
> compile-tests:
> Created dir: /export/home/dtftest/gump/results/ant/build/testcases
> Compiling 287 source files to /export/home/dtftest/gump/results/ant/build/testcases
> /export/home/dtftest/gump/results/ant/src/tests/junit/org/apache/tools/ant/taskdefs/SQLExecTest.java:209: NullDriver is not abstract and does not override abstract method getParentLogger() in Driver
> public static class NullDriver implements Driver {
Ahh, JDBC is changing in backwards incompatible ways again. Even if we
fix Ant's tests you will find lots of breaking projects downstream
later.
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 (which
is the minimum version of Java supprted by Ant).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org