Stefan Bodewig wrote:
On Thu, 07 Jul 2005, Kev Jackson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
