[Soot-list] How to reuse CFG framework without low-level byte code.

[Chris Pickett]

emujrock at verizon.net wrote:

> Yes, you may call it ?refactoring?.  I need to remove goto form the original language just to make it legal *.java

I guess technically refactoring has to do legal source to legal source 
transformations of the same language.  Java bytecode and Jimple do allow 
goto, so it would help if Java source code isn't mandatory for you.

However, as you probably know, Java can get goto-like functionality in 
other ways, through the use of break, continue, labels, and 
try...catch...finally:

http://java.sun.com/developer/TechTips/2000/tt0613.html#tip2

>>It does seem likely that somebody else has encountered this problem, and you might try looking for an Eclipse plugin.  Googling turns up the jGRASP project, which provides graphical CFG views of >Java source.
> 
> 
> Thanks, I will have a look.
> 
> I looked at the classes which do ?goto elimination?. I found CycleFinder, IfFinder and so on. I was playing with them to do some refactoring. My Goal would be to replace Jimple classes IfStmt,? with some adapters to allow them to be used with other languages. Also adding some unit tests would be great.
> 
> In case I may succeed. What is your outside submission policy if you have any. Will the change be accepted back into the main tree? I would like to avoid maintaining separate branches.

I am not a Soot maintainer, but basically if you submit a patch and it 
doesn't break anything and the current Soot maintainer deems it to be 
acceptable, it will get applied.  No promises, but obviously good work 
is welcomed.  Of course you have to be able to license your work under 
the LGPL too.

> Sincerely, Pavel
> 
> BTW. A few general questions about source code.
> 
> 1.	Do you plan to move to Java 1.5. You have a lot of untyped collections and generifying the code would clarify it.

There is work being done on Java 1.5.  I'm not sure about its status. 
You should check out a working copy of the Soot trunk from Subversion 
for all recent changes -- in fact, you should do this anyway.  Then svn 
log and svn diff will tell you more.

> 2.	What are the thought about replacing you log with Apache common-logging. It will decrease the number of singletons significantly. 

Feel free to elaborate and/or do this, although you probably want to 
sort out your goto problem first.

> 3.	I saw some discussion in the previous mails about possible removing of singletons. Any move in that direction?

Not that I know of... but I'm also not at McGill at the moment.

Cheers,
Chris