Question

As the title says, when attempting to do folder.open() it fails, doesn’t throw an error though so it is proving hard to find a reason. In my debug console the following error does appear but it may/may not be related (This only shows up after pressing resume after the folder.open() breakpoint).

I am using the JavaMail API for Android for development. Everything was working fine for IMAP servers but I need to be able to connect to POP3 mail servers also. The store being connected to is GMAIL and all the neccessary settings have been changed on my GMAIL account.

04-12 13:22:26.682: INFO/dalvikvm(436): Ljava/lang/IllegalStateException;: Folder is not Open
04-12 13:22:26.682: INFO/dalvikvm(436):     at com.sun.mail.pop3.POP3Folder.checkOpen(POP3Folder.java:512)
04-12 13:22:26.682: INFO/dalvikvm(436):     at com.sun.mail.pop3.POP3Folder.close(POP3Folder.java:227)
04-12 13:22:26.682: INFO/dalvikvm(436):     at com.sun.mail.pop3.POP3Folder.finalize(POP3Folder.java:506)
04-12 13:22:26.682: INFO/dalvikvm(436):     at dalvik.system.NativeStart.run(Native Method)

The connection method for pop3 is as follows:

String SSL_FACTORY = "javax.net.ssl.SSLSocketFactory";

        Properties pop3Props = new Properties();

        pop3Props.setProperty("mail.pop3.socketFactory.class", SSL_FACTORY);
        pop3Props.setProperty("mail.pop3.socketFactory.fallback", "false");
        pop3Props.setProperty("mail.pop3.port",  "995");
        pop3Props.setProperty("mail.pop3.socketFactory.port", "995");

        URLName url = new URLName("pop3", "pop.gmail.com", 995, "",
                "******@googlemail.com", "*****");

        //session = Session.getInstance(pop3Props, null);
        Session session = Session.getInstance(pop3Props, new javax.mail.Authenticator() 
        {   
            protected PasswordAuthentication getPasswordAuthentication() 
            {
                return new PasswordAuthentication("***********", "*****");
            }
        });

        session.setDebug(true);

        store = new POP3SSLStore(session, url);
        store.connect();

The method for connecting to a store is as follow (Where the problems are being encountered):

folders = store.getFolder("INBOX");
        //Folder folder = store.getFolder("INBOX");
        if (folders.isOpen()) 
        {
            if ((folders.getMode() & Folder.READ_WRITE) != 0) 
            {
                folders.close(false);
                folders.open(Folder.READ_ONLY);
            }
        } 
        else 
        {
            try
            {
                folders.open(Folder.READ_ONLY);
            }
            catch (Exception e)
            {
                Log.i("Folder Opening,", e.toString());
            }
        }

Any ideas would be helpful! Session has been debugged and no problems are apparent. If any more information is needed for you to assist do not hesitate to ask! I’m sure I’m not the only person getting this problem.

Thanks!
Rhys

Answer 1

So, we came across this issue as well.

I took a look at the implementation of POP3Folder where that exception is being triggered.

It seems that POP3Folder is overriding finalize() in order to perform some cleanup before the object goes out of existence. The finalize() override calls close() which checks if the folder is open, and if it isn’t, the IllegalStateException you see is thrown.

This is why you may be seeing it sporadically; it happens when the GC comes along to take a look at your object, and at that point, the folder may have been closed already, so by the time finalize() calls close(), the check to see if the folder is open will throw the exception.

Now, I can’t speak to whether this is smart or dumb. It does seem that the code would be better if close() would just ignore the fact that the folder is already closed and move along, instead of throwing an exception.

POP3Folder takes a parameterized constructor. Unfortunately, it isn’t public or protected, so you can’t simply derive from it and override the close() method, removing the check for whether the folder is open.

But, since the exception call stack originates from finalize(), it should make it less of a danger to leave alone, since any exception thrown from finalize() will typically only halt the finalization process (garbage collection) for that object, without causing much more damage.

Would love to see a proper solution to this, though.