[1795] in java-interest

home help back first fref pref prev next nref lref last post

Re: JDK Question

daemon@ATHENA.MIT.EDU (Thomas Ball)
Sun Sep 17 00:50:45 1995

Date: Fri, 15 Sep 1995 11:48:14 -0700
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
To: phil@bolthole.com
Cc: java-interest@java.Eng.Sun.COM


>  From daemon@java  Thu Sep 14 22:39:31 1995
>  Subject: Re: JDK Question
>  To: java-interest@java.Eng.Sun.COM
>  Mime-Version: 1.0
>  Content-Transfer-Encoding: 7bit
>  X-Info: To unsubscribe, send 'unsubscribe' to java-interest-request@java.sun.com
>  
>  > > I just downloaded the Developer's Kit and am starting to
>  > > convert my Java Applets.  I have been using the NetworkClient
>  > > class under net.  Does that no longer exist?  Did anything
>  > > replace it or should I write my own network class?
>  > 
>  > It has moved to sun.net. This means that it is not going to
>  > be supported by all Java enabled browsers.
>  > 
>  
>  meaning, it won't work for netscape under mac, or whatever.
>  
>  They should have moved it to unix.net or something.

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.  Netscape has
the right to develop a "netscape" set of classes if they wish, and
other licensees may wish to develop their own.  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.

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).

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. :-)

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.

Tom Ball
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post