javamail cannot issue UID FETCH and doesn't fully support workaround

[glassfishrobot]

Javamail doesn't support UID FETCH at present. You can get a Message by UID and then do a FETCH by sequence number, but that's an extra round trip.

The semi-obvious workaround for this is to use Folder.doCommand() and issue a UID FETCH of your own:

    folder.doCommand(p -> {
        p.simpleCommand("UID FETCH", args);
        return null;
    });

And this works... mostly. If there's a message with that UID in the folder, the IMAP server will return an untagged FETCH response which will be caught by Protocol.simpleCommand() and handed off to Protocol.notifyResponseHandlers() and then to IMAPFolder.handleResponse(). It finally lands in IMAPFolder.processFetchResponse(), which handles UID, MODSEQ, FLAGS, and extensions. Everything else is dropped. (IMAPFolder.handleResponse also sends a MessageChangedEvent, which is not optimal, but it's not an issue for me as I don't have any listeners active on the Folder.)

Would it be possible to either

a) support UID FETCH directly, or
b) have IMAPFolder.processFetchResponse() handle at least a larger subset of the other fetch items, like IMAPMessage.handleFetchItem() does?

Affected Versions

1.5.5

Environment

PC
Mac OS

[glassfishrobot]

@glassfishrobot Commented
Reported by dkarp

[glassfishrobot]

@glassfishrobot Commented
@bshannon said:
IMAP was designed around sequence numbers, and JavaMail follows that model.
Changing JavaMail to allow you to operate using only UIDs without ever
needing sequence numbers is possible; it's only software after all. But
it's also a fairly large amount of work to do it in a way that doesn't
break the existing model. Rearranging the code to allow workarounds has
significant risk without directly addressing the problem.

Addressing this has been on my wish list for years, but it's unlikely to
be addressed anytime soon.

What performance data do you have showing that the extra round trip is an
actual problem in a real application? By using getMessagesByUID you should
only need one additional round trip per session, which should be insignificant
if you're doing operations on many messages in the Folder.

[glassfishrobot]

@glassfishrobot Commented
dkarp said:
Each user generally has a lot of mailboxes, and it's not feasible to keep an open Folder for each of them. But sequence numbers don't persist, so the application has to track UIDs between SELECTs.

IMAP may have been built around sequence numbers, but UID FETCH/STORE/SEARCH are required IMAP 4 commands. An IMAP library certainly doesn't have to support them. But they were put in the protocol for this very reason.

[glassfishrobot]

@glassfishrobot Commented
@bshannon said:
If you're opening and closing Folders frequently I would think the connection
setup cost would far dominate the additional round trip. Still, if you have
actual numbers, I'd love to see them. I'm sure removing the extra round
trip will be better, but I'd like to know how much better. 1%? 10%?

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from Bugzilla JAVAMAIL-7088

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/javamail/issues/197
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @bshannon