Login | ViewVC Help
View File | Revision Log | Show Annotations | Download File | View Changeset | Root Listing
root/javautils/ViaThinkSoft Java Utils/lib/javamail-1.4.3/COMPAT.txt
Revision: 7
Committed: Mon Jun 14 07:55:39 2010 UTC (10 years ago) by daniel-marschall
Content type: text/plain
File size: 4956 byte(s)
Log Message:
Java Mail komplett hinzugefĆ¼gt

File Contents

# Content
1 COMPATIBILITY NOTES
2 ===================
3
4 JavaMail(TM) API 1.4.3 release
5 ------------------------------
6
7 The JavaMail 1.4 specification is fully compatible with the JavaMail
8 1.3 specification. However, changes in the implementation may impact
9 applications that depend on behavior beyond what is defined by the
10 JavaMail specification, or that use features specific to the Sun
11 implementation. This note summarizes potential compatibility issues
12 with this release of the JavaMail API.
13
14
15 -- JavaMail 1.4.3 --
16
17 - SMTPTransport.isConnected behavior changed
18
19 The SMTPTransport.isConnected method uses the SMTP NOOP command
20 to determine if the server is still alive. Because many older
21 servers were broken in various ways, any response (other than
22 the 421 "connection timed out" response) was considered a
23 successful response and the server was considered to be still
24 alive. Unfortunately, Microsoft Exchange has a bug that causes
25 it to return a response code of 451 when it times out a connection
26 instead of the expected 421 response code. SMTPTransport.isConnected
27 now considers only a 250 response code to indicate success, per
28 the SMTP spec. The old behavior can be restored by setting the
29 new mail.smtp.noop.strict property to false.
30
31
32
33 -- JavaMail 1.4.2 --
34
35 - mail.smtp.quitwait default changed
36
37 In previous releases, JavaMail would drop the SMTP connection
38 to the server immediately after sending the QUIT command.
39 This violates the SMTP spec. The property "mail.stmp.quitwait"
40 controls this behavior. In this release the default behavior
41 (if the property isn't specified) has changed so that JavaMail
42 will wait for the response from the server before dropping the
43 connection. In some cases, with some servers, this additional
44 wait time may be noticable.
45
46
47 - MessagingException.getMessage output changed
48
49 The MessagingException class, which is the base class for all
50 JavaMail exceptions, has been retrofitted to support the
51 exception chaining feature added to the java.lang.Throwable
52 class in J2SE 1.4. The visible impact of this change is that
53 the String returned by the getMessage method will only return
54 the immediate message for the top level exception, instead of
55 including messages for all nested exceptions.
56
57
58 - connection timeouts no longer use a thread
59
60 To support connection timeouts in older versions of the JDK,
61 it was necessary for JavaMail to create a thread to make the
62 connection, so that it could interrupt and abandon that
63 thread if the connection timeout expired. J2SE 1.4 added
64 the ability to specify the connection timeout directly, so
65 JavaMail no longer uses an additional thread for this purpose.
66
67
68 - ByteArrayDataSource now part of javax.mail.util
69
70 The ByteArrayDataSource class, which was previously included
71 in source form in the demo directory, is now a standard part
72 of the JavaMail API in the new javax.mail.util package.
73 Applications that are modified to make use of classes in the
74 new package, and that also included a copy of the demo version
75 of ByteArrayDataSource, should be careful to avoid potential
76 name conflicts between these two classes.
77
78
79 - mail.SSLSocketFactory.class property no longer supported
80
81 The JavaMail implementation previously used this undocumented
82 property to locate the SSLSocketFactory from which it would
83 create SSLSockets when making an SSL or TLS connection. This
84 property is no longer used. The standard
85 javax.net.ssl.SSLSocketFactory is used instead, which supports
86 a standard way of overriding the choice of default SSLSocketFactory.
87 See the SSLSocketFactory javadocs for details. Most applications
88 should never need to override the default SSLSocketFactory.
89
90
91 - Quota class moved from com.sun.mail.imap to javax.mail
92
93 The new Quota APIs in JavaMail are taken directly from the old
94 IMAP-specific classes in the com.sun.mail.imap package. If you've
95 been using these classes, you'll need to update your application
96 to use the new classes in the javax.mail package.
97
98
99 - getProtocol method removed from com.sun.mail.imap.IMAPFolder
100
101 The getProtocol method returns an instance of IMAPProtocol.
102 This was originally intended to allow applications to
103 experiment with extending the IMAP protocol support to use IMAP
104 commands not directly implemented by the IMAP protocol
105 provider. Unfortunately, to safely use the IMAPProtocol
106 object, you need to obey the locking requirements of the
107 IMAPFolder object, and there's no way to do that from outside
108 the IMAPFolder object. The doCommand method was added to
109 IMAPFolder to resolve this problem. Now, with the introduction
110 of IDLE support to the IMAP protocol provider, it's critical to
111 obey the locking requirements. To prevent mistakes, the old,
112 unsafe, getProtocol method has been removed. Applications
113 should use the doCommand method for simple IMAP extensions.
114 Use of more complex IMAP extensions may require modification
115 of the IMAP protocol provider.