The DEVELOPING_OPAL/demos/ dir seems like a good place to start. However,
Just gives me this error:
/root/OPAL/./DEVELOPING_OPAL/demos/src/main/scala/org/opalj/br/ClassFileInformation.scala:2: error: illegal start of definition
/root/OPAL/./DEVELOPING_OPAL/demos/src/main/scala/org/opalj/br/ClassFileInformation.scala:3: error: illegal start of definition
two errors found
I also tried running sbt in the OPAL dir and while the update command worked, the publish command (it seems to be compiling the project) failed apparently due to issues reaching external servers.
What's a good place for me to start? Thanks!
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