David Liebeherr wrote:
Johan Compagner wrote:
There has been over 10 years of Java development without generics.
I doubt that the introduction of generics makes the casts much
unsafer than the previous 10 years.
Sorry, but: Do you realy belive wroking without generics is as safe
as working with them?
There are serious reasons that Java has generics now.
If you don't understand that then it may be that you have missed
something fundamental about generics.
That is not what martijn was saying!
We have developed pretty good application from day 1 with java until
the latest version of 1.4.2 so not having generics wasn't a BIG
problem in all those years.
Well he said that he doubts that generics make casts safer.
My quote: 'I doubt that the introduction of generics makes the casts
much unsafer than the previous 10 years.'
So, I said: the introduction of generics don't make the casts 'UNsafer'.
I know that generics make casts obsolete and programs more typesafe. But
they don't make the current pre-tiger way of developing any more UNsafe
than after tiger.
All I meant was: this is the way we have been developing for 10 years
with these casts. Great frameworks have been developed, and are being
developed using pre-tiger technology. No big problems have arisen during
these 10 years, mandating that we should upgrade /NOW/ to 1.5.
There are lots of languages without static typing, and people (other
than me) can write great, safe, programs in those languages.
In short, I'm all for using generics, when we upgrade to JDK 1.5/Java
5/Tiger. But I'm for using it ONLY where they are NEEDED. Not just
because they are there, but at those points where true benefits can be
gained. I have seen many C++ developers die horrible deaths just because
someone /needed/ to use templates.
PS: What's about using the tool whichs converts 1.5 bytecode to 1.4
class file somone mentioned a while ago? So we could use generics an
still be able to provide the core to 1.4 users.
I'm against this. It introduces yet another layer on top of an already
complex stack of technologies. When we upgrade to 1.5/Tiger/Java5, we
should also drop concurrent.jar and use the java.concurrent package. So
you'd also have a library problem.
Introducing such a technology will inherently create support problems
when for instance the IBM, BEA, Oracle JDK doesn't play nice with the
backported code. I don't want to debug/support such a stack of technologies.
This might be an option when 80% of our users are 1.5/Tiger/Java5
converts, and 20% is still running 1.4.
Martijn
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
