As far as Java developers should be concerned, those API do not exist. They
are undocumented, unsupported, and you are warned against using them. Sun
has no obligation to those people that rely on those classes.
Scott
> -----Original Message-----
> From: Patrick McGovern [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 17, 1999 11:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Servlet using sun.net.smtp.SmtpClient?
>
>
> One might ask...then why does sun include these api's in the
> JDK releases? I think enough people are using this particular
> set of classes that sun would be foolish to make any changes
> that would break existing code. I, personally, cant include
> my code in JDK releases (although it would make my life
> easier) so sun shouldnt either.
>
> Patrick
>
> >>> "Craig R. McClanahan" <[EMAIL PROTECTED]> 03/17
> 11:15 AM >>>
> Jason Hunter wrote:
>
> > Danny Rubis wrote:
> > >
> > > But, but... Jason Hunter uses this in one of his examples
> > > in his new book.
> > >
> > > Jason can you please comment on this.
> > >
> > > Thank you Chris.
> >
> > As it says in the book: "For the purposes of this example, we'll
> > demonstrate a servlet that uses the sun.net.smtp.SmtpClient class.
> > It's conveniently provided with Sun's JDK and most JVMs descended
> > from it, but we should warn you that it's unsupported and subject
> > to change (though it hasn't changed since JDK 1.0)."
> >
> > I personally find SmtpClient much easier to use than JavaMail. I've
> > used both, and even teach a servlets class that
> demonstrates the use of
> > both. In the lab I let students choose which they want to use and I
> > haven't seen anyone choose JavaMail yet! :-)
> >
> > JavaMail requires the installation of two .jar files (and therefore
> > modifications to the server classpath), and has an API
> clearly designed
> > for robust mail handling services driven by a front end GUI, not
> > programatically sending a simple text email to one person. It's the
> > politically correct way to go, however. That's why I gave
> the warning,
> > and made sure to provide the URL for JavaMail in the book.
> >
> > Course, I personally would rather use a third party SmtpClient
> > equivalent before JavaMail in my servlets. That way you can be
> > politically correct *and* enjoy a simple API. I'll use JavaMail
> > when I'm writing a GUI mailer. That's the use for which it was
> > designed.
> >
> > -jh-
> >
> > --
> > Jason Hunter
> > [EMAIL PROTECTED]
> > Book: http://www.servlets.com/book
> > Article: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html
> >
>
> This is going to sound a little harsh, but IMHO it is
> irresponsible for a
> respected author to encourage Java developers to learn and
> use bad habits. I
> already have to undo enough bad habits in Java developers
> that I utilize ... I
> don't need more of them.
>
> Throughout the JDK documentation, you will find warnings
> against the use of
> the sun.* series of APIs, because they only represent the Sun
> implementation
> of particular features. They are undocumented and subject to
> change, so that
> anyone who relies on them is risking the correct behavior of
> their code when
> they do something as innocent as upgrading to the next rev.
> The fact that
> this particular class has not changed yet is no excuse!
>
> If you don't want to use JavaMail, that's fine ... it is
> overkill for sending
> a simple EMAIL message from a servlet. But there are lots of
> open source
> examples of simple SMTP senders that you could have included
> in your utility
> classes (and these would work even if you are running on a
> JVM that is *not*
> provided by Sun, and does not include this class :-).
>
> Relying on sun.net.smtp.SmtpClient in a Java program is a
> poor programming
> practice -- just as poor as relying on "undocumented" Windows
> APIs when
> programming in the Microsoft arena.
>
> Craig McClanahan
>
>
> >
> >
> ______________________________________________________________
> _____________
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives:
> http://archives.java.sun.com/archives/servlet-> interest.html
> >
> Resources:
> http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ______________________________________________________________
> _____________
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
> http://java.sun.com/products/servlet/external-> resources.html
>
> LISTSERV Help:
> http://www.lsoft.com/manuals/user/user.html
>
> ______________________________________________________________
> _____________
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
> http://java.sun.com/products/servlet/external-> resources.html
>
> LISTSERV Help:
> http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
