Gilbert Carl Herschberger II wrote:
> Give compatibility a chance.
I agree that compatibility is an issue worthwhile discussing. I just
have a few constructive things to add to the discussion:
- Sun give (IMHO) sufficient warning of API changes through the use of
the @deprecated javadoc tag. In this way, if Sun plans to remove a
method from the API, it takes two JDK versions to happen. In the next
version, the method is still there but deprecated. In the version after,
it may be removed.
- Sun appears to have used this tool effectively, except with Swing
which underwent a package renaming. Obviously the @deprecated tool
cannot be used here, and coincidently it was this Swing incompatibility
that fired the discussion off.
I don't see the point in bashing Sun, but I do see that compatibility is
something that we should consider. It is conceivable that Sun could, for
example, change the JVM specification making new JVMs incompatible with
older JVMs, or that they could make incompatible changes to the JDK
libraries. However, call me short-sighted but I just don't think it is
something worth worrying about now -- at this point in the project
timeline. Someone will need to think about these issues in the future.
Actually, you sound quite keen. Why don't you come up with a proposal?
--
Ryan Heise
http://www.progsoc.uts.edu.au/~rheise/
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
