docker run -it --rm opalj/sbt_scala_javafx
sbtto start the sbt console changed to the subproject Demos
project Demosand started one of the provided Demo programs using
run(e.g. 21 - ClassFileInformation).
https://bitbucket.org/OPAL-Project/myopalprojectas a starting point. It is a preconfigured project that can readily be imported into IntelliJ (it should also work with ATOM/Visual Studio Code with the appropriate Scala plugins/extensions).
The sbt docs I've run across seem to assume the scenario where there is a single project and don't explain how I choose a project and provide command line arguments when there are multiple options. I also don't see a way to figure out where the jar file is and run it from the regular command line. How would I do that?
Also, all the demos contain the code of individual analyses. Where is the source code for their driver? Thanks!
Hi @Delors, what do you think about the following topic:
The SimpleTACAI stores results internally in a map . I noticed that this can become a bottleneck if you want to store other large results in addition while the development machine does not have that much RAM. I tested a quick hack where I wrote a NonPersistenceSimpleTACAI which does not store results internally. This worked fine for me. However, I think the approach taken in BaseAI and AI looks more promising. There it's possible to switch certain properties on and off through final constructor params . I thought about preparing a PR with first draft similar to . What do you think?
CallersPropertyfor example. Is that path no longer correct or what else might cause this issue ?
tac. Depending on your usage scenario you may have to update your project dependency.
@majestocx Regarding the Call Graph:
Call Graphs in Opal are represented as two distinct properties, handling either the callers of a certain method (
org.opalj.br.fpcf.cg.properties.CallersProperty), or for a given call site (method and program counter) the set of potential targets (
In order two retrieve these properties for a given Method you have to do the follwing three steps:
1: Build the call graph.
val ps = project.get(PropertyStoreKey) val manager = project.get(FPCFAnalysesManagerKey) implicit val declaredMethods = project.get(DeclaredMethodsKey) manager.runAll( RTACallGraphAnalysisScheduler, TriggeredStaticInitializerAnalysis, TriggeredLoadedClassesAnalysis, TriggeredFinalizerAnalysisScheduler, TriggeredThreadRelatedCallsAnalysis, TriggeredSerializationRelatedCallsAnalysis, TriggeredReflectionRelatedCallsAnalysis, TriggeredInstantiatedTypesAnalysis, TriggeredConfiguredNativeMethodsAnalysis, TriggeredSystemPropertiesAnalysis, LazyCalleesAnalysis( Set( StandardInvokeCallees, SerializationRelatedCallees, ReflectionRelatedCallees, ThreadRelatedIncompleteCallSites ) ), LazyL0BaseAIAnalysis, TACAITransformer )
“Convert” a method to declared method
val dm = declaredMethods(method)
Retrieve the callers/callees for that declared method:
ps(dm, CallersProperty.key /*Callees.key*/)
I have to admit, that this is rather complicated.
Unfortunately, a more elegant way to retrieve the call graph is under development right now, and only available at the