When there are no attachments, we are still trying to parse the attachment which leads to NullPointerException. Shall we have an if condition so that the attachments will be parsed only if hasAttachments is true.

I could see you have fixed it but it is not available in 0.7.0

Whenever we retrieve a value from the json field, we use .toString() which could throw NullPointerException. That field may be allowed to have null but since we have .toString() we would end up with NPE. This PR aims at avoiding such NPE. Its a better alternative to null check.
PFB the PR raised for the same.
#7

There are some methods which only gives asynchronous option.
Like delete method in JMailTM class, or save method in Attachment class.

For me it looks like a good idea to give a synchronous version of this method.
It doesn't look a hard task to do since these methods have similar format(just some code snippet surrounded by new Thread(new Runnable() { ... }).start();).

So I'll be happy to do some contribution myself, but I'm not sure what is best option to achieve the goal.

1. Just make new synchronous method named like deleteNow

• code would be like this :

    /**
     * (Synchronous) Deletes the Self Account
     */
    public void deleteNow(){
        try{
                IO.requestDELETE(baseUrl+"/accounts/"+id , bearerToken);
        }catch (Exception e){
                System.out.println("|EXCEPTION IGNORE | "+e);
        }
    }
    /**
     * (Asynchronous) Deletes the Self Account
     */
    public void delete(){
        new Thread(this::deleteNow).start();
    }

• This would be a easy option, not effecting legacy code.
• It may cause naming confusion, XX(Asynchronous) <-> XXNow(Synchronous) naming pattern doesn't match existing code like asyncXX(Asynchronous) <-> XX(Synchronous) (see fetchMessages)

2. Follow existing naming pattern

• code would be like this :

    /**
     * (Synchronous) Deletes the Self Account
     */
    public void delete(){
        try{
                IO.requestDELETE(baseUrl+"/accounts/"+id , bearerToken);
        }catch (Exception e){
                System.out.println("|EXCEPTION IGNORE | "+e);
        }
    }
    /**
     * (Asynchronous) Deletes the Self Account
     */
    public void asyncDelete(){
        new Thread(this::deleteNow).start();
    }

• There will be no naming confusion to users.
• This does effect legacy code, making many existing code/project broken.

3. Make delete method returns Future object

• Make a Thread Pool, and submit all asynchronous tasks(deleting account, saving attachments, fetching mails, etc..) to it.
• In this case, submit method will return a Future object.
• So it will be easy to wait for the thread, and WorkCallback class will be easily changed to Future<Boolean>
• It is likely not to effect legacy code, since only return type of the method is changed. But, some rare case(e.g. method referencing like jmailtmObjectList.stream().foreach(JMailTM::delete)) will result an error.
• A Thread Pool is used, so we should be careful to avoid bottleneck.(but Thread Pool looks like a better option than making new thread every time calling a method)

What would be the best option?