ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Death of a mutant ...
Date Thu, 11 Jul 2002 16:56:06 GMT
On Thu, 11 Jul 2002, Stephane Bailliez wrote:

> I agree with you here but cannot really judge the real benefits, so I would
> say the smallest code base, the better.


It's the interfaces and the core that are important here - we'll leave 
with them for many years, and not only us - but thousands of people.

> > As for JDK1.1 compat - I'm strongly against making the new interfaces 
> > require 1.2. There is absolutely no justification. I'm ok with using
> > 1.2 in the implementation - since 1.1 implementations will be 
> > possible.
> I must be missing something.
> How do you plan to make it work in a 1.1 if your implementation is 1.2 ?

As long as the interface doesn't use JDK1.2 features ( and that's not 
_that_ difficult !) and the code is modular ( as it should ) - I can
use a different implementation that is not using 1.2.

In most cases using a package like tomcat.compat it is quite easy
to turn a 1.2 class into 1.1 ( at least the Thread/classloader/security
can be replaced with single-liners, without any introspection ).

And nobody says _all_ features must be available on 1.1 - just
the basic stuff and what's reasonable. 

> > I hope everyone realize how many users ant has - I suspect more people
> > use ant than JDK1.4 today. There are huge investments in time and 
> > learning, books, etc. If we really want a new API for future 
> > - it better be _very_ good.
> No one asked for JDK 1.4 so don't extrapolate.

What I meant - ant has a huge user base, and our responsibility should
be as big as that of Sun when it makes changes in the JDK. 

BTW, there is nothing wrong with using JDK1.3 or JDK1.4 in implementation,
if it provides clear benefits - as long as the code is modular and
a JDK1.1 (minimal) implementation is possilbe, or that feature is not 

> I'm tired of Enumeration, toArray(), Vector/Hashtable, isFile()
> !isDirectory() or use reflection to get some benefits of JDK 1.2 methods if
> available. No need to reinvent and recode what has already been done and
> exists. Why should I need to recode a Manifest class ? unecessary code. We
> have load of unecessary codes like this. Should it be for creating a temp
> file. For copying the content of a vector into an array. etc...

Using reflection is clearly a bad solution. Again, it is possible to
provide a clean solution, using a simple wrapper for most things.

As long as the code is modular and the _interfaces_ are 1.1 compatible -
it is perfectly fine for the new code to use JDK1.2. And if someone
needs one of those new features in a 1.1 build - he can do the 
required work.

Well, if everyone else feels 1.1 shouldn't be supported - it only takes 
a vote to remove that requirement. Even for 1.6 - the commiters set
the rules. I won't -1 it.

But I would -1 using 1.2 stuff in interfaces or removing 1.1
support in essential classes. When we finalize a new core - 
it will be possible to have different modules without problem
and clean up the 'official' ones. 


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

View raw message