More Details on Soot and -allow-phantom-refs

In the previous post I mentioned that I’m trying to create a call graph of all of DrJava using Soot. Since DrJava is a cross-platform application, there are classes that get compiled and used only on certain operating systems. The classes in the com.apple.eawt package, for instance, are only used on the Mac.

That means that Soot doesn’t normally find these classes when generating the call graph with Sun JDKs:

resolving [from .class]: edu.rice.cs.drjava.platform.MacPlatform$1
Exception in thread "main" java.lang.RuntimeException:
couldn't find class: com.apple.eawt.ApplicationListener
(is your soot-class-path set properly?)
    at soot.SootResolver.bringToHierarchy(SootResolver.java:184)
    at soot.SootResolver.bringToSignatures(SootResolver.java:219)
    at soot.SootResolver.bringToBodies(SootResolver.java:260)
    at soot.SootResolver.processResolveWorklist(SootResolver.java:135)
    at soot.SootResolver.resolveClass(SootResolver.java:124)
    at soot.Scene.loadClass(Scene.java:390)
    at soot.Scene.loadClassAndSupport(Scene.java:375)
    at soot.Scene.loadNecessaryClasses(Scene.java:963)
    at soot.Main.run(Main.java:169)
    at soot.Main.main(Main.java:145)

Setting the Soot -allow-phantom-refs option doesn’t really help; it gets past the initial stages, but later still has errors:

Exception in thread "main" soot.AbstractSootMethodRef$ClassResolutionFailedException:
Class com.apple.eawt.ApplicationEvent doesn't have method setHandled([boolean]) : void;
failed to resolve in superclasses and interfacesLooking in com.apple.eawt.ApplicationEvent
which has methods []
    at soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:135)
    at soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:95)
    at soot.jimple.internal.AbstractInvokeExpr.getMethod(AbstractInvokeExpr.java:54)
    at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.getImplicitTargets
        (OnFlyCallGraphBuilder.java:234)
    at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod
        (OnFlyCallGraphBuilder.java:182)
    at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables
        (OnFlyCallGraphBuilder.java:81)
    at soot.jimple.toolkits.callgraph.CallGraphBuilder.build(CallGraphBuilder.java:84)
    at soot.jimple.toolkits.callgraph.CHATransformer.internalTransform(CHATransformer.java:43)
    at soot.SceneTransformer.transform(SceneTransformer.java:39)
    at soot.SceneTransformer.transform(SceneTransformer.java:45)
    at soot.SceneTransformer.transform(SceneTransformer.java:50)
    at dk.brics.soot.callgraphs.CallGraphExample$2.internalTransform(CallGraphExample.java:88)
    at soot.SceneTransformer.transform(SceneTransformer.java:39)
    at soot.Transform.apply(Transform.java:89)
    at soot.ScenePack.internalApply(ScenePack.java:43)
    at soot.Pack.apply(Pack.java:114)
    at soot.PackManager.runWholeProgramPacks(PackManager.java:409)
    at soot.PackManager.runPacks(PackManager.java:329)
    at soot.Main.run(Main.java:202)
    at soot.Main.main(Main.java:145)

What I did instead was make the Apple classes available on Windows and Linux as well, just on the Soot classpath (they aren’t actually loaded by the JVM), but then I run into an 8-year-old Java bug in the garbage collector. Fixing Soot is more likely than fixing the JVM.

Update

After checking out Soot from the svn repository and building it from scratch, the Soot problem has gone away, but now I still run into the 8-year-old Java bug in the garbage collector.