Possible flaw of JavaMOP

[emopers]

During our monitoring, we noticed that for several properties JavaMOP would trigger violations at locations where there were no possible violated calls, while it seems to have nothing to do with the properties themselves. Those properties include Iterator_HasNext, ByteArrayOutputStream_FlushBeforeRetrieve, Socket_InputStreamUnavailable, Socket_OutputStreamUnavailable.
One typical situation where such kind of violations could be triggered in Iterator_HasNext is shown as the following:

T first = iterator.next();
if(iterator.hasNext()) {
...
}

We have seen many violations that JavaMOP will trigger alarms not only on the call of next(), but on hasNext() as well.
Another typical situation where ByteArrayOutputStream_FlushBeforeRetrieve got violated was that, the program either flush() or close() the wrapper of ByteArrayOutputStream, but still get violated when calling ByteArrayOutputStream.toByteArray().
Similarly, for Socket_InputStreamUnavailable, Socket_OutputStreamUnavailable, we have seen the violation at this line when monitoring terraform project.

import java.net.Socket;
import java.net.SocketAddress;
import java.net.InetSocketAddress;
import java.io.IOException;

public class Socket_InputStreamUnavailable {
    public static void main(String[] args) {
        Socket s = null;
        String host = "127.0.0.1";
        //Any port not in use
        int port = 9327;
        try {
            s = new Socket();
            s.setReuseAddress(true);
            SocketAddress sa = new InetSocketAddress(host, port);
            s.connect(sa, 3000);
            return;
        }
        catch (IOException e) { }
        finally {
            if (s != null) {
                try {
                    s.close();
                } catch (IOException e) {
                }
            }
        }
    }
}

No call to Socket.getOutputStream / getInputStream is made but it still violated at s.close().

Our guess for such cases are that there were some internal states within JavaMOP that was not reset as we cannot find any problems with the properties, and such false alarms seemed do not happen in a deterministic way.