Re: Extend Jimple keywords

[Chris Pickett <chris.pickett@mail.mcgill.ca>]

Hi Duy,

Isn't it better to leave Jimple alone and make the Java end of JJJC deal 
with recognizing your new keywords or methods and translating them back 
and forth from Jimple?

If you leave Jimple alone, then you have an easy way to transform your 
programs to bytecode, which means they will run on any VM.  The only 
reason I can think of for modifying Jimple itself is to allow for some 
new kind of analysis not currently possible (or perhaps just not easy) 
with the Soot framework, or to allow for non-standard bytecode output 
(in which case you need to modify a VM as well). 

Basically ... what are you trying to do?  What is this "state explosion" 
problem?  What are the specific transformations you want to make?  What 
are the semantic results of these transformations?  Do they allow for 
new paradigms at the programming / design / source level (Java) or the 
execution level (bytecode)?

Cheers,
Chris

VO Duc Duy wrote:

> Very good remark! thank you.
> we actually use a tool called Java-Jimple-Java compiler (JJJC) and of 
> course it doesn't generate Jimple from class file but directly from 
> java source. That's why I have modified this JJJC in order that it 
> understands my input file. But basically, this tool also uses the 
> jimple library of Soot, that's why I have to modify also in Jimple of 
> Soot!
>
> If I generate jimple from class file, then all the library calls (such 
> as the methods addCase, searchPair in last email) will also be in byte 
> code, then the program will generate a lot of states (state 
> exploision). That's why I want to put these methods in library of 
> jimple and JJJC.
>
> ---------------------
> I got your second email about Bandera. You are right! Bandera is a 
> tool that I want to intergrate my language. I have modified its 
> grammar (using sablecc) and now I try to introduce the new keywords 
> (in jimple) for my language.
>
> If you still have any question, please tell me.
> Thank you for your quick answer, it helps me alot.
> Duy.
>
> Navindra Umanee wrote:
>
> > VO Duc Duy <duy.voduc@epfl.ch> wrote:
> >  
> >
> > > I am using jimple in my project (integration of our synchonous java 
> > > language to Bandera), but the input file is not 100% java syntax, it 
> > > has some new keywords, so I have to extend jimple in order to cover 
> > > my keywords.
> > >   
> >
> >
> > How are you producing Jimple from Java code in general?  Are you using
> > some kind of Java2Jimple frontend?  Are you expecting to output
> > bytecode with your extended Jimple?
> >
> > The reason I ask is that, typically in Soot, Jimple would be generated
> > from a class file (ie bytecode) and not the Java source, although the
> > next release will also have JavaToJimple. 
> > In your case, if you can produce valid bytecode from your Extended
> > Java, you should have nothing left to do for Soot/Jimple.
> >
> > Cheers,
> > Navin.
> >
> >