Actually, that isn 't a good reason. Anytime anyone wants to
'maintain backwards compatibility' when better functionality is available
is wrong. When there is nothing lost, or it can be done in such a way as
to allow concurrent version support, fine. But to maintain old, outdated
API's just because someone doesn't want to update is bad. It leads to code
that is less then optimal. The collection API has been around a while, and
is a much better way of handling collections than in JDK 1.1.
As to being JDK agnostic, this is wrong as well. It is all well and
good in theory, but the reality of the situation is that if a particular
JDK feature can have a significant impact, it is well worth doing. An
example of this would be is some feature of JDK x.x were to double
performance speed. What good does agnosticism do when it leads to least
common denominator support? Sort of like running code compiled for a 386
on a Pentium 4.
Your sponsor's do not allow you to keep castor free, or opensource.
It already is, and that can't change. Yes, you may have rights to the name
Caster, but all the code is out there, and that can't change. You have
already licensed it in a way that anyone at anytime can take the source to
start their own project with. Apache is a good example of this. There are
projects they have cooped because the authors ended up at odds with their
user community for whatever reason. Velocity is based off of WebMacro,
where this happened.
And no, I'm not trying to attack anyone. I'm just pointing out what I
feel are the direct fallacies of your post. Sure it is possible to design
a software project in such a way that different configurations are
possible, and if castor is doing that, great. It is more work to do so,
but is usually worth it.
Keith Visco
<kvisco@intal To: [EMAIL PROTECTED]
io.com> cc:
Subject: Re: [castor-dev] Castor patch to
generate Java2
02/10/02 Collections ArrayList code instead of Array
[]
01:51 AM
Please
respond to
castor-dev
"Dirk P. Fromhein" wrote:
>
> Why is that?
>
> I can think of one reason (that I hope is not the reason - applet
> compatibility with "old" browsers, not a feature I care about at all).
>
How about, because our sponsors want us to keep JDK 1.1 compatability.
Do you think that's a good enough reason? I think it's a great
reason...they make it possible for Castor to remain free of charge and
open source.
> In the area of Collections, 1.2 added some very important functionality.
> Why not support it? (I for one feel it is essential)
I never said we wouldn't support 1.2...AND WE DO have support for 1.2 in
both the source code generator and the mapping framework.
I simply said, we need to maintain JDK 1.1 compatability. JDK 1.2
compatability needs to be added in a way that it doesn't break JDK 1.1
compatability, that's all.
Castor-XML needs to remain JDK agnostic. This simply means we need to be
creative when we add support for JDK 1.2, such as using collection
handlers and wrapper classes, etc.
Glenn is maintaining his changes and has made them available. So if you
wish to use them, feel free to do so. That's why he made them available.
For people like you, who feel it's essential.
Thanks,
--Keith
>
> Keith Visco wrote:
>
> >Hi Glenn,
> >
> >We can't use your patch. Castor XML is maintaining JDK 1.1
> >compatability. The Marshaller cannot include JDK 1.2+ collections.
> >
> >Thanks,
> >
> >--Keith
> >
> >[munch]
> >
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
