These are the internal classes that make up the runtime of the system, it's
like saying that since all operating systems have internal device
manipulation calls, why not call them directly instead of using the accepted
C or C++ interfaces to those calls. These aren't "hidden treasure" that are
there for the taking, there are real risks involved in using undocumented
(actually these are documented as "DON'T USE") code. It's just bad
practice, especially when there are numerous alternatives.
(*Chris*)
----- Original Message -----
From: Patrick McGovern <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 1999 8:54 AM
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
