java.lang.Objectjavax.mail.Folder
Direct Known Subclasses:
SimpleFolder
Folders can contain Messages, other Folders or both, thus providing a tree-like hierarchy rooted at the Store's default folder. (Note that some Folder implementations may not allow both Messages and other Folders in the same Folder).
The interpretation of folder names is implementation dependent. The different levels of hierarchy in a folder's full name are separated from each other by the hierarchy delimiter character.
The case-insensitive full folder name (that is, the full name relative to the default folder for a Store) INBOX is reserved to mean the "primary folder for this user on this server". Not all Stores will provide an INBOX folder, and not all users will have an INBOX folder at all times. The name INBOX is reserved to refer to this folder, when it exists, in Stores that provide it.
A Folder object obtained from a Store need not actually exist
in the backend store. The exists
method tests whether
the folder exists or not. The create
method
creates a Folder.
A Folder is initially in the closed state. Certain methods are valid
in this state; the documentation for those methods note this. A
Folder is opened by calling its 'open' method. All Folder methods,
except open
, delete
and
renameTo
, are valid in this state.
The only way to get a Folder is by invoking the
getFolder
method on Store, Folder, or Session, or by invoking
the list
or listSubscribed
methods
on Folder. Folder objects returned by the above methods are not
cached by the Store. Thus, invoking the getFolder
method
with the same folder name multiple times will return distinct Folder
objects. Likewise for the list
and listSubscribed
methods.
The Message objects within the Folder are cached by the Folder.
Thus, invoking getMessage(msgno)
on the same message number
multiple times will return the same Message object, until an
expunge is done on this Folder.
Note that a Message's message number can change within a session if the containing Folder is expunged using the expunge method. Clients that use message numbers as references to messages should be aware of this and should be prepared to deal with situation (probably by flushing out existing message number references and reloading them). Because of this complexity, it is better for clients to use Message objects as references to messages, rather than message numbers. Expunged Message objects still have to be pruned, but other Message objects in that folder are not affected by the expunge.
John
- ManiBill
- ShannonNested Class Summary: | ||
---|---|---|
static class | Folder.TerminatorEvent |
Field Summary | ||
---|---|---|
protected Store | store | The parent store. |
protected int | mode | The open mode of this folder. The open mode is
Folder.READ_ONLY , Folder.READ_WRITE ,
or -1 if not known.
|
public static final int | HOLDS_MESSAGES | This folder can contain messages |
public static final int | HOLDS_FOLDERS | This folder can contain other folders |
public static final int | READ_ONLY | The Folder is read only. The state and contents of this folder cannot be modified. |
public static final int | READ_WRITE | The state and contents of this folder can be modified. |
Constructor: |
---|
|
Methods from java.lang.Object: |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Method from javax.mail.Folder Detail: |
---|
The implementation provided here adds this listener to an internal list of ConnectionListeners. |
The implementation provided here adds this listener to an internal list of FolderListeners. |
The implementation provided here adds this listener to an internal list of MessageChangedListeners. |
The implementation provided here adds this listener to an internal list of MessageCountListeners. |
Folder implementations must not abort this operation if a Message in the given message array turns out to be an expunged Message. |
A CLOSED ConnectionEvent is delivered to any ConnectionListeners registered on this Folder. Note that the folder is closed even if this method terminates abnormally by throwing a MessagingException. |
Note that the specified Message objects must belong to this folder. Folder implementations might be able to optimize this method by doing server-side copies.
This implementation just invokes |
If the creation is successful, a CREATED FolderEvent is delivered to any FolderListeners registered on this Folder and this Store. |
The
|
|
getMessageNumber method
on each of these message objects returns that Message's original
(that is, prior to the expunge) sequence number. A MessageCountEvent
containing the expunged messages is delivered to any
MessageCountListeners registered on the folder. Expunge causes the renumbering of Message objects subsequent to the expunged messages. Clients that use message numbers as references to messages should be aware of this and should be prepared to deal with the situation (probably by flushing out existing message number caches and reloading them). Because of this complexity, it is better for clients to use Message objects as references to messages, rather than message numbers. Any expunged Messages objects still have to be pruned, but other Messages in that folder are not affected by the expunge.
After a message is expunged, only the |
Clients use this method to indicate that the specified items are needed en-masse for the given message range. Implementations are expected to retrieve these items for the given message range in a efficient manner. Note that this method is just a hint to the implementation to prefetch the desired items. An example is a client filling its header-view window with the Subject, From and X-mailer headers for all messages in the folder.
Message[] msgs = folder.getMessages(); FetchProfile fp = new FetchProfile(); fp.add(FetchProfile.Item.ENVELOPE); fp.add("X-mailer"); folder.fetch(msgs, fp); for (int i = 0; i < folder.getMessageCount(); i++) { display(msg[i].getFrom()); display(msg[i].getSubject()); display(msg[i].getHeader("X-mailer")); } The implementation provided here just returns without doing anything useful. Providers wanting to provide a real implementation for this method should override this method. |
|
This method can be invoked on a closed folder. However, note that for some folder implementations, getting the deleted message count can be an expensive operation involving actually opening the folder. In such cases, a provider can choose not to support this functionality in the closed state, in which case this method must return -1. Clients invoking this method on a closed folder must be aware that this is a potentially expensive operation. Clients must also be prepared to handle a return value of -1 in this case.
This implementation returns -1 if this folder is closed. Else
this implementation gets each Message in the folder using
|
exists() method on a Folder indicates whether it really
exists on the Store. In some Stores, name can be an absolute path if it starts with the hierarchy delimiter. Otherwise, it is interpreted relative to this Folder. Folder objects are not cached by the Store, so invoking this method on the same name multiple times will return that many distinct Folder objects. This method can be invoked on a closed Folder. |
This method can be invoked on a closed Folder. |
Message objects are light-weight references to the actual message that get filled up on demand. Hence Folder implementations are expected to provide light-weight Message objects. Unlike Folder objects, repeated calls to getMessage with the same message number will return the same Message object, as long as no messages in this folder have been expunged. Since message numbers can change within a session if the folder is expunged , clients are advised not to use message numbers as references to messages. Use Message objects instead. |
This method can be invoked on a closed folder. However, note that for some folder implementations, getting the total message count can be an expensive operation involving actually opening the folder. In such cases, a provider can choose not to support this functionality in the closed state, in which case this method must return -1. Clients invoking this method on a closed folder must be aware that this is a potentially expensive operation. Clients must also be prepared to handle a return value of -1 in this case. |
This implementation invokes |
Message objects are light-weight references to the actual message that get filled up on demand. Hence Folder implementations are expected to provide light-weight Message objects.
This implementation uses getMessage(index) to obtain the required
Message objects. Note that the returned array must contain
|
Message objects are light-weight references to the actual message that get filled up on demand. Hence Folder implementations are expected to provide light-weight Message objects.
This implementation uses getMessage(index) to obtain the required
Message objects. Note that the returned array must contain
|
Folder.READ_ONLY , Folder.READ_WRITE ,
or -1 if the open mode is not known (usually only because an older
Folder provider has not been updated to use this new
method). |
This method can be invoked on a closed Folder. |
This method can be invoked on a closed folder. However, note that for some folder implementations, getting the new message count can be an expensive operation involving actually opening the folder. In such cases, a provider can choose not to support this functionality in the closed state, in which case this method must return -1. Clients invoking this method on a closed folder must be aware that this is a potentially expensive operation. Clients must also be prepared to handle a return value of -1 in this case.
This implementation returns -1 if this folder is closed. Else
this implementation gets each Message in the folder using
|
Note that since Folder objects are not cached, invoking this method returns a new distinct Folder object. |
The special flag The supported permanent flags for a folder may not be available until the folder is opened. |
|
|
|
|
This method can be invoked on a closed folder. However, note that for some folder implementations, getting the unread message count can be an expensive operation involving actually opening the folder. In such cases, a provider can choose not to support this functionality in the closed state, in which case this method must return -1. Clients invoking this method on a closed folder must be aware that this is a potentially expensive operation. Clients must also be prepared to handle a return value of -1 in this case.
This implementation returns -1 if this folder is closed. Else
this implementation gets each Message in the folder using
|
RECENT flag set. Note that this is not an incremental check for new mail, i.e., it cannot be used to determine whether any new messages have arrived since the last time this method was invoked. To implement incremental checks, the Folder needs to be opened. This method can be invoked on a closed Folder that can contain Messages. |
|
This method can be invoked on a closed Folder. The default implementation provided here just returns true. |
list(String pattern)
method with "%" as the match pattern. This method can
be invoked on a closed Folder. |
"%" , which matches any character except hierarchy
delimiters, and "*" , which matches any character. As an example, given the folder hierarchy: Personal/ Finance/ Stocks Bonus StockOptions Jokes list("*") on "Personal" will return the whole
hierarchy. list("%") on "Personal" will return "Finance" and
"Jokes". list("Jokes") on "Personal" will return "Jokes".list("Stock*") on "Finance" will return "Stocks"
and "StockOptions". Folder objects are not cached by the Store, so invoking this method on the same pattern multiple times will return that many distinct Folder objects. This method can be invoked on a closed Folder. |
listSubscribed(String pattern) method with "%"
as the match pattern. This method can be invoked on a closed Folder. |
list .
(The default implementation provided here, does just this).
The pattern can contain wildcards as for list .
Note that, at a given level of the folder hierarchy, a particular
folder may not be subscribed, but folders underneath that folder
in the folder hierarchy may be subscribed. In order to allow
walking the folder hierarchy, such unsubscribed folders may be
returned, indicating that a folder lower in the hierarchy is
subscribed. The Folder objects are not cached by the Store, so invoking this method on the same pattern multiple times will return that many distinct Folder objects. This method can be invoked on a closed Folder. |
The provided implementation queues the event into an internal event queue. An event dispatcher thread dequeues events from the queue and dispatches them to the registered ConnectionListeners. Note that the event dispatching occurs in a separate thread, thus avoiding potential deadlock problems. |
The implementation provided here queues the event into
an internal event queue. An event dispatcher thread dequeues
events from the queue and dispatches them to the
FolderListeners registered on this folder. The implementation
also invokes |
The implementation provided here queues the event into
an internal event queue. An event dispatcher thread dequeues
events from the queue and dispatches them to the
FolderListeners registered on this folder. The implementation
also invokes |
The provided implementation queues the event into an internal event queue. An event dispatcher thread dequeues events from the queue and dispatches them to the registered MessageCountListeners. Note that the event dispatching occurs in a separate thread, thus avoiding potential deadlock problems. |
The provided implementation queues the event into an internal event queue. An event dispatcher thread dequeues events from the queue and dispatches them to registered MessageChangedListeners. Note that the event dispatching occurs in a separate thread, thus avoiding potential deadlock problems. |
The provided implementation queues the event into an internal event queue. An event dispatcher thread dequeues events from the queue and dispatches them to the registered MessageCountListeners. Note that the event dispatching occurs in a separate thread, thus avoiding potential deadlock problems. |
If this folder is opened successfully, an OPENED ConnectionEvent is delivered to any ConnectionListeners registered on this Folder. The effect of opening multiple connections to the same folder on a specifc Store is implementation dependent. Some implementations allow multiple readers, but only one writer. Others allow multiple writers as well as readers. |
The implementation provided here removes this listener from the internal list of ConnectionListeners. |
The implementation provided here removes this listener from the internal list of FolderListeners. |
The implementation provided here removes this listener from the internal list of MessageChangedListeners. |
The implementation provided here removes this listener from the internal list of MessageCountListeners. |
If the rename is successful, a RENAMED FolderEvent is delivered to FolderListeners registered on this folder and its containing Store. |
This implementation invokes
|
Note that the specified Message objects must belong to this folder.
This implementation iterates through the given array of messages,
and applies the search criterion on each message by calling
its |
Note that the specified Message objects must
belong to this folder. Certain Folder implementations can
optimize the operation of setting Flags for a group of messages,
so clients might want to use this method, rather than invoking
This implementation degenerates to invoking |
Certain Folder implementations can
optimize the operation of setting Flags for a group of messages,
so clients might want to use this method, rather than invoking
The default implementation uses |
Certain Folder implementations can
optimize the operation of setting Flags for a group of messages,
so clients might want to use this method, rather than invoking
The default implementation uses |
This method can be invoked on a closed Folder. The implementation provided here just throws the MethodNotSupportedException. |
|