ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: XJ - xml extension for Java
Date Thu, 07 Jul 2005 11:51:44 GMT
Stefan Bodewig wrote:
> On Thu, 07 Jul 2005, Kev Jackson <kevin.jackson@it.fts-vn.com> wrote:
> 
> 
>>I guess Stefan will want to wait until kaffe, gjc etc support 1.5
>>properly before we move anything.
> 
> 
> Not really.  Personally I don't see and going to require 1.5 too soon,
> but my reasons are different.
> 
> One of our customers runs 1.3 in their "web center".  There is no way
> anybody can change that.  They plan on upgrading to 1.4 by the end of
> the year.  In theory I could run Ant in a JSDK 5 (or whathever it is
> called), but if I run Ant on a JDK 1.3, I can be sure my code is going
> to work on their system as well - and doesn't get compiled against
> method signatures that have been added post JDK 1.3.
> 
> I know that I'm not the only one in a position like this.  If you are
> dealing with big companies that are not IT companies in the first
> place, you are quite likely to meet very conservative sysadmins.
> 
> And then you need to ask yourself what you are going to gain by
> dropping support for JDK X.  Which feature of JDK 1.3 would you want
> to use that would make our live easier?  Is it worth dropping 1.2
> support?  Which feature of 1.4?  Is it worth dropping 1.3 and 1.2
> support?
> 
> The transition from 1.1 to 1.2 was far more obvious to me.  For
> classloader stuff much more than for collections, all in all there was
> a lot to gain by the move.  So far I don't see any language feature
> after that that would improve Ant's code if only we could use it.
> 
> There are certain class library changes - like having a
> FileOutputStream constructor that takes a File and a boolean as
> arguments - that would be nice to have, but nothing pressing IMHO.
> 

There are some nice features in the classlibs, both tuning of the core 
stuff (Closeable) and extra new things. Like a good xml parser as 
standard, formatted strings, but otherwise? lets see

Generics: good for new code, where you really dont care about backwards 
compatibility.

enhanced for: looks pretty, but doesnt actually do anything new

Varargs: yes, you can have some fun there. String.Format(); need I say more?

Attributes. This can be powerful, or it can be abused. I fear that java 
will copy .net and go for attributes everywhere, making the code a 
mishmash of declarative and procedural stuff. More to the point, for all 
that everyone hates about writing XML descriptors everywhere, the nice 
thing about them is that you can decouple late-binding information from 
the source. With attributes (and in the past, XDoclet), people can put 
stuff in the source that should not be there.

There is no one thing that is compelling. I actually suspect attributes 
are the most interesting...we could add ant support so that you can have 
attributes on methods that indicate which methods are/are not bound to 
XML data, perhaps provide extra diagnostics information for IDEs 
(popups), etc.

But to do so is abandon the older platforms, which will be a long time 
coming. At least with classlib extensions you can use introspection 
tricks to get at the new features without old code breaking;  with 
language changes you make a bold jump to the java5+ world.

I'm writing some new stuff in Java1.5+ only. My prototype soap stack 
(M32  - first road to the alps), is 1.5+ only, So is some of the stuff I 
do for grid deployment (but not the smartfrog core, oh no). I'm 
gradually building up some new classes to integrate existing code (like 
Xom) with the new language features; it is starting to work ok.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message