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

[Patrick LAM]

On Mon, 11 Jul 2005 emujrock at verizon.net wrote:

> >I assume the goto elimination is a *refactoring* taking place because
> >you want maintainable Java source code.
>
> Yes, you may call it ?refactoring?.  I need to remove goto form the
> original language just to make it legal *.java

Running the code through Dava would give you legal Java source code, if
you could create bytecode for it somehow.  An easy way to do this might be
to generate bytecode from the AST of your legacy code; or you could create
Grimp code, which can then be converted into bytecode.

> 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.

If your code is more generally applicable then we might commit it into the
main tree.  If it's just useful for your one-time legacy code conversion,
then it doesn't seem like a good thing to put into the tree itself.

> 1. Do you plan to move to Java 1.5. You have a lot of untyped
> collections and generifying the code would clarify it.
>
> 2. What are the thought about replacing you log with Apache
> common-logging. It will decrease the number of singletons significantly.
>
> 3. I saw some discussion in the previous mails about possible removing
> of singletons. Any move in that direction?

Keep in mind that Soot is a research framework primarily developed by
graduate students as part of their research; any improvements that don't
directly help people do research are unlikely to be someone's priority.
If you're interested in doing one of these things, discuss it on the list
(before starting) and after it's done it might be committable.

The singletons that are problematic aren't really due to logging, they're
due to keeping persistent state around; switching to another logging
framework won't help that much.

As for Java 1.5, there are changes going on which allow Soot to process
1.5-generated bytecode, but I'm not aware of any changes to have Soot use
parametric polymorphism in its own implementation at the moment.

pat