ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <dic...@nortelnetworks.com>
Subject RE: [PATCH] refactoring of javac task into factory
Date Sat, 16 Dec 2000 03:26:10 GMT
> I like a lot Jay's proposal and arguments. The only thing I 
> would suggest
> is some sort of more declarative way of mapping between "modern",
> "classic" etc and appropriate classes. That would make 
> possible, for other
> compilers implementation to declare their own names, which 
> would be used
> instead of fully qualified class names. 

Actually, I've already introduced a subtle change in my patch already.  I've
introduced a compiler called "Java1.3" that maps to "modern" (actually, the
other way around).  I've never liked the relativness of "modern" and
"classis".  What happens when javac 1.4 comes out.  Will it be called "Ultra
Modern".  What about javac1.5?  "Uber Modern"?  When javac1.5 comes out,
what will the definition of classic become?  This is why I've introduced the
subtle change (backwards compatible though) of compiler names likes
javac1.1, javac1.2 and javac1.3.  For more information, see the diff for
index.html.

> 
> I have not checked the solution to the compiler specific 
> attributes from
> the patch though - how for example 'pedantic' for jikes is 
> being solved?

Good question.  How do we solve compiler specific parameters?  For things
like extdirs, the logic could be accommodated to all situations.  But things
like pedantic for jikes is applicable only to Jikes.  One possible solution
would be through magic parameters, where each compiler adapter would look
for the ones that concerned them.  Another possible solution would be to add
a new parameter to the javac task (something like extraParams) and it would
be up to the compiler adapter to properly interpret these parameters.  For
example, the javac1.3 compiler adapter would read "pedantic", doesn't
understand it and so ignores it.  However, I don't like either solution.

> Once this issue is cleared, and once this patch will make its 
> way to the
> ANT CVS, I would think this model should be reused for all 
> others optional
> groups of tasks sharing common funcionality - maybe even 
> generic interface
> based framework shuold be created for it.
> 
> cheers
> Mariusz
> 
> 

JDGlanville

Mime
View raw message