[1819] in java-interest
Re: JDK Question
daemon@ATHENA.MIT.EDU (Scott Treacy)
Mon Sep 18 09:47:48 1995
Date: Mon, 18 Sep 1995 11:41:02 +0000
To: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
From: S.P.Treacy@scotborders.co.uk (Scott Treacy)
Cc: java-interest@java.sun.com
[STUFF DELETED]
>Baloney! All of Sun's browsers will support the sun classes,
>regardless of the hardware or operating system they run on. The "sun"
>hierarchy includes classes we've developed which aren't part of the
>Java standard our licensees (and ourselves) are bound by.
So, Why are they there? OR to put it another way, Why are they not
included in the Java Standard?
>Netscape has the right to develop a "netscape" set of classes if they wish,
>and other licensees may wish to develop their own.
God Help us... just look at the mess they have made of HTML3! Sure
they have the best browser in the short term but at what cost?
>Over time, some of these extensions may move to common area if Sun and our
>licensees agree. That way we can have a standard developers can rely on
now, >and yet be one that can grow. It's a common approach for "open systems"
>APIs.
Just because it's common dosen't mean its right!
Ever hear of RFC's? Thats the IS right way to do it!
>If you want to develop an applet guaranteed to run on all Java-enabled
>browsers, stick to the java.* classes. If you want to use an extension,
>you lock yourself into that subset of browsers which support that
>extension (just like with other API standards).
So as usual we end up with a non-standard standard!
Looks like you've been taking lessons from Microsoft!
>In theory, it should be possible to try dynamically loading an extension
>in a try-catch block (using Class.forName()), and take alternative
>action if it fails. So if Netscape also offers something similar to
>the NetworkClient class, a smart applet can try one and then the other
>to see which type of NetworkClient to use. I haven't tried this yet,
>however, so your mileage may vary. :-)
Kludge, Kludge, Kludge why do we always have to have a kludge!
More lessons from Microsoft!
BTW if we have to live with this Kludge maybe it's not to late to add
a static method to java.lang.system along the lines of getOSName
called getBrowserName??? OR is this a problem whith the Licensees...
>In a perfect world, the first cut at an API would be perfect for all
>time, for all present and future systems, and be implemented the day
>the spec is finalized -- there wouldn't be any need for extensions then.
>Until that happens, all we can do is make our best effort at both
>defining APIs as well as we can, and making our best effort toward
>making upgrading less painful for developers. As a future Java ISV,
>I think we've done pretty well at this.
Time will tell but I think some pretty large mistakes have taken place
but, as Microsoft always seem to get away with it, I think Sun will
manage to do the same with Java!
>Tom Ball
Scott
Scott Treacy - Java Development Team, TweedNet, Calligrafix.
aka Work - Tel: +44 (0) 1835 822990 Fax: +44 (0) 1573 430206
Elgeebar Smail: 1 Tweed Horizons Centre, St. Boswells, Scotland. TD6 0SG.
UNet#question Home - Tel: +44 (0) 1896 870490 Fax: +44 (0) 1896 757965
Smail: 17 Park Villa, Walkerburn, Borders, Scotland. EH43 4AN.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
