WALA VS. SOOT (Method Declaration)

walaVSsoot2.md

• The method void setRequestMethod(java.lang.String) is declared in class java.net.HttpURLConnection.
• The methods void setDoInput(boolean) and void connect() are declared in class java.net.URLConnection.

JAVA SOURCE CODE

 private void connect() throws IOException{
    	URL url = new URL(URL);
    	HttpURLConnection conn = (HttpURLConnection) url.openConnection(); 
        conn.setRequestMethod("GET");
        conn.setDoInput(true);
        conn.connect();
}

---

JIMPLE FROM WALA SOURCE CODE FRONT END

    private void connect() throws java.io.IOException
    {
        de.ecspride.ActivityLifecycle1 r0;
        java.net.URL $r1;
        java.lang.String $r2;
        java.net.URLConnection $r3;
        java.net.HttpURLConnection $r4;

        r0 := @this: de.ecspride.ActivityLifecycle1;
        $r1 = new java.net.URL;
        $r2 = <de.ecspride.ActivityLifecycle1: java.lang.String URL>;
        specialinvoke $r1.<java.net.URL: void <init>(java.lang.String)>($r2);
        $r3 = virtualinvoke $r1.<java.net.URL: java.net.URLConnection openConnection()>();
        $r4 = (java.net.HttpURLConnection) $r3;
        
        virtualinvoke $r4.<java.net.HttpURLConnection: void setRequestMethod(java.lang.String)>("GET");
        virtualinvoke $r4.<java.net.URLConnection: void setDoInput(boolean)>(1);
        virtualinvoke $r4.<java.net.URLConnection: void connect()>();

        return;
    }

---

JIMPLE FROM SOOT BYTE CODE FRONT END

    private void connect() throws java.io.IOException
    {
        de.ecspride.ActivityLifecycle1 $r0;
        java.net.URL $r1;
        java.net.URLConnection $r2;
        java.lang.String $r3;
        java.net.HttpURLConnection $r4;
        
        $r0 := @this: de.ecspride.ActivityLifecycle1;
        $r1 = new java.net.URL;
        $r3 = <de.ecspride.ActivityLifecycle1: java.lang.String URL>;
        specialinvoke $r1.<java.net.URL: void <init>(java.lang.String)>($r3);
        $r2 = virtualinvoke $r1.<java.net.URL: java.net.URLConnection openConnection()>();
        $r4 = (java.net.HttpURLConnection) $r2;
        
        virtualinvoke $r4.<java.net.HttpURLConnection: void setRequestMethod(java.lang.String)>("GET");
        virtualinvoke $r4.<java.net.HttpURLConnection: void setDoInput(boolean)>(1);
        virtualinvoke $r4.<java.net.HttpURLConnection: void connect()>();

        return;
    }

While both of these Jimple IRs are correct in some sense, the bytecode IR refers to methods that dot not actually exist but rather are inherited from a base class. As long as everyone who asks questions always resolves the method, this is ok. But it does mean that naively asking whether two target methods are the same can produce wrong answers. For this reason, the WALA front ends always resolve methods.

There are sometimes reasons, due to method visibility issues, that the bytecode has to refer to non-existent methods. However, there seems to be no reason why a compiler IR needs to, and it might be simpler to resolve the method (and field) references as WALA does.