ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: issues with ant
Date Thu, 11 Nov 2010 20:35:55 GMT
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.


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

View raw message