[Soot-list] Soot changes method signature after de-compilation from jimple to java

Wed Apr 30 12:12:17 EDT 2014

Hi Tony,

Thank you. I already merged the pull request. Good to have that issue fixed.

Best regards,
  Steven

-----Ursprüngliche Nachricht-----
Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Dacong Yan
Gesendet: Mittwoch, 30. April 2014 17:21
An: Steven Arzt
Cc: Soot Mailing List
Betreff: Re: [Soot-list] Soot changes method signature after de-compilation from jimple to java

Hi Steven,

Just did that. See <https://github.com/Sable/soot/pull/202>.

Thanks,
Tony

On Wed, Apr 30, 2014 at 11:18 AM, Steven Arzt <Steven.Arzt at cased.de> wrote:
> Hi Dacong and Souvik,
>
> If you can confirm that this patch fixes the problem, can you please open up a pull request on Github?
>
> Best regards,
>   Steven
>
> -----Ursprüngliche Nachricht-----
> Von: soot-list-bounces at CS.McGill.CA 
> [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Dacong Yan
> Gesendet: Mittwoch, 30. April 2014 17:15
> An: Souvik Pal
> Cc: Soot Mailing List
> Betreff: Re: [Soot-list] Soot changes method signature after 
> de-compilation from jimple to java
>
> Hi Souvik,
>
> This is due to a minor problem with the particular way that dava prints class constants such as User.class. The method signature is actually not changed.
>
> A simple test case is the following.
>
> ClassConst.java:
>
> public class ClassConst {
>   public static void main(String[] args) {
>     print(ClassConst.class);
>   }
>
>   static void print(Class c) {
>     System.out.println(c);
>   }
> }
>
> Run "soot -f d ClassConst", and look at the outputted sootOutput/ClassConst.java. You will see the same problem.
>
> Suggested fix is to change src/soot/dava/DavaUnitPrinter.java
> (https://github.com/dacongy/soot/commit/37a93bc87bf919b6fb53cd0952a0e2ff90375ff7).
>
> Thanks,
> Tony
>
> On Wed, Apr 30, 2014 at 10:03 AM, Souvik Pal <write2souvikpal at gmail.com> wrote:
>> Hi,
>> First of all sorry for this late reply.
>>
>>
>> On Tue, Apr 29, 2014 at 6:46 PM, Marc-André Laverdière 
>> <marc-andre.laverdiere-papineau at polymtl.ca> wrote:
>>>
>>> Hi Souvik,
>>>
>>> First, Soot 2.3 is really really old. Have you given thought to 
>>> upgrading to 2.5? Or even better, the cutting-edge development branch?
>>
>>
>> Will definitely try to upgrade to latest version of soot. I hope that 
>> the transition would be smooth.
>>
>>>
>>> Second, I don't understand what you are asking for... what do you 
>>> mean by 'original signature of the API'?
>>
>>
>> Let me explain the problem in detail.
>>
>> I have a Java application that uses Hibernate (a popular ORM for 
>> Java) for persisting objects in database. In Hibernate, on of the 
>> most popular ways to retrieve an object from database (into memory) 
>> is by using the API session.get. It takes the class of the user 
>> defined object and the primary key or essentially the unique id of 
>> that object as parameters. So the signature of this API is
>>
>> java.lang.Object get(java.lang.Class, java.io.Serializable)
>>
>> Now, my task is to analyse such java application which uses Hibernate 
>> APIs and suggest possible optimization. Optimizations can be as 
>> simple as live variable analysis or constant propagation. I need to 
>> reproduce the java application with transformation embedded, i.e. with a few 'dead-codes'
>> deleted or some lines of the code modified capturing the effect of 
>> constant propagation.
>>
>> For this I am using SOOT. I am using Jimple as intermediate 
>> representation, analysing the code, adding suitable transformation 
>> and then decompiling the Jimple into Java. This is where the problem 
>> arises. While converting the Java to Jimple, the java statement 
>> containing the Hibernate API session.get changes as follows into Jimple statement.
>>
>> Java Statement:  User user1 = (User) session.get(User.class, 1); // 
>> assume 1 as an the id of the User object to be retrieved
>>
>> Jimple Statement(s):
>> $r1 = staticinvoke <java.lang.Integer: java.lang.Integer
>> valueOf(int)>(1)
>>
>> // User class is located in package testProject.hibernate.examples
>> $r2 = interfaceinvoke session.<org.hibernate.Session: 
>> java.lang.Object
>> get(java.lang.Class,java.io.Serializable) > (class 
>> "testProject/hibernate/examples/User", $r1)
>>
>> In the decompiled program (using dava), the same Java statement appears as:
>>
>> User user1 = (User) session.get(class 
>> "testProject/hibernate/examples/User",
>> Integer.valueOf(1))
>>
>> So the first argument of the API changed from User.class to class 
>> "testProject/hibernate/examples/User"
>> Hibernate can not recognize this, and the re-written (optimize) java 
>> program fails to compile.
>>
>> I am interested to know how can I get rid of this issue. Will 
>> upgrading to latest SOOT version solve this issue?
>>
>> Thanks and regards.
>>
>>
>>
>>>
>>> Marc-André Laverdière-Papineau
>>> Doctorant - PhD Candidate
>>>
>>> On 04/29/2014 06:43 AM, Souvik Pal wrote:
>>> > Hi all,
>>> >
>>> > I am new to soot. I am using soot (soot 2.3) to analyze simple 
>>> > Hibernate programs.
>>> >
>>> > Hibernate *session.get* API requires a *java.lang.Class* and
>>> > *java.io.Serializable* type arguments. However when I am 
>>> > de-compiling the Jimple expressions into java, the API signature 
>>> > changes and Hibernate can not recognize it.
>>> >
>>> > Example.
>>> >
>>> > *User aUser = (User) session.get(User.class, 1);* get transformed 
>>> > to in the de-compiled program.
>>> > *aUser = (User) session.get(class
>>> > "path/to/class/User", Integer.valueOf(1));*
>>> >
>>> > The intermediate Jimple statements are
>>> >
>>> > *$r1 = staticinvoke <java.lang.Integer: java.lang.Integer
>>> > valueOf(int)>(1)
>>> > *
>>> > *$r2 = interfaceinvoke session.<org.hibernate.Session:
>>> > java.lang.Object get(java.lang.Class,java.io.Serializable)>(class
>>> > "**path/to/class/User**", $r1)*
>>> >
>>> >
>>> > Please let me know what should I do to keep the original signature 
>>> > of the API.
>>> >
>>> > Thanks and regards,
>>> >
>>> > --
>>> > *Souvik Pal*
>>> >
>>> >
>>> > _______________________________________________
>>> > Soot-list mailing list
>>> > Soot-list at CS.McGill.CA
>>> > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>>> >
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at CS.McGill.CA
>>> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>>
>>
>>
>>
>> --
>> Souvik Pal
>> Student M. Tech.,
>> CSE, IIT Bombay
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at CS.McGill.CA
>> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>>
>
>
>
> --
> Dacong (Tony) Yan
> Ph.D. Student
> Computer Science and Engineering
> The Ohio State University, Columbus
> http://www.cse.ohio-state.edu/~yan
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>

--
Dacong (Tony) Yan
Ph.D. Student
Computer Science and Engineering
The Ohio State University, Columbus
http://www.cse.ohio-state.edu/~yan
_______________________________________________
Soot-list mailing list
Soot-list at CS.McGill.CA
https://mailman.CS.McGill.CA/mailman/listinfo/soot-list