>I have mixed feelings (to say the least) about parametric/generic stuff
>in java so I will not comment further on this.
What are these mixed feelings you're referring to? At one point in the past
I thought generic programming was only necessary if you didn't have a common
base class, like in C++, but the more I use Java and compare it to C++ I
realize that the type safety lost by the Java model of collections is a
definite draw back that needs to be addressed. The abuse of casting that is
indused by Java's collections library is just poor design.
>Cool it is (I don't know why I was thinking Magic). Anyway I totally
>agree with you about the need to seperate Sun from Java - "nothing good
>will come from this" is the phrase that comes to my mind. I to hope (if
>not yet believe) that Java will become _the_ next platform and it would
>be best to settle this issue as early as possible. Removing the profit
>motive I think puts it to simply though - C/C++ vendors have a rpofit
>motive - but with a published ANSI/ISO standard whatever "clever
>add-ons" that mightcome up with, they are just that and it's the profit
>motive (ie. "the market") that makes them all try to meet the standard.
Your right, "profit motive" is a bit vague. What I was trying to express
with that fraise was an issue that Linux users are familiar with -- Sun
wants Solaris to be the best platform for Java and sometimes this is a
conflict of interest (aka "profit motive"). So maybe we should speak of an
environment where changes to Java are made for purly technical reasons. This
is similar to what Linus claims he has achieved with Linux, and why it is
such a good OS.
>Well hopefully one of the "elder statesmen" will correct me if I'm wrong
>on this, but my understanding is that there were lots of vendors all
>selling C compilers+libs and each implemented K&R C plus what ever
>"extensions" they felt like. Now Borland/M$/Watcomm/gcc/etc all made a
>name for themselves selling products that were at least mostly complaint
>to a spec, even if they all did have their own wierd propreitery
>extensions. Even if the vendors weren't terribly happy about
>standardisation (again I'm not very knowledgeable on the history of
>these events - though I can't imagine all they vendors were thrilled by
>standardisation) they all put out compliant products eventually - full
>stop.
This is interesting but I don't think that this development model is
directly applicable to Java (Sun's or not) -- not that I think you're
implying that. The ideal way to develop something like Java is in a
community environment where everyone is working democratically on a common
code base, thus avoiding splintering. To allow the choices to be made in the
marketplace exposes developers to the sort of games that M$ plays with their
APIs.
>Now today we have the same thing with java dev tools, but since with
>java they are only half the game, the same thing needs to occur with the
>java (jvm+class libs) platform.
Right, but like I said above, these enhances should not be added by
companies as extentions but democratically in a community process.
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
