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