Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 28 2020 12:05
    pushed to delors/opal
    Merged in florian_kuebler/readmemarkdown-edited-online-with-bitbuc-1578400042961 (pull request #534) Updated Readme.markdown with deprecation/github migration statement Approved-by: errt <helm@cs.tu-darmstadt.de> (compare)
  • Apr 28 2020 12:05
    pushed to delors/opal
    0 commits
  • Jan 07 2020 12:28
    pushed to delors/opal
    Updated Readme.markdown with deprecation/github migration statement (compare)
  • Oct 10 2019 13:54
    pushed to delors/opal
    A few minor adaptions (compare)
  • Oct 10 2019 13:23
    pushed to delors/opal
    Formatting... (compare)
  • Oct 10 2019 13:16
    pushed to delors/opal
    Measure performace on 5 runs (compare)
  • Oct 07 2019 11:35
    pushed to delors/opal
    Adapt to changes in OPAL implementation (compare)
  • Aug 30 2019 11:52
    pushed to delors/opal
    fixed an issue related to the removal of dependers from a final EPK state (compare)
  • Aug 30 2019 09:09
    pushed to delors/opal
    3 commits
  • Aug 30 2019 09:04
    pushed to delors/opal
    Don't schedule PointsTo Analysis for other CGs (compare)
  • Aug 29 2019 14:32
    pushed to delors/opal
    2 commits
  • Aug 29 2019 14:27
    pushed to delors/opal
    3 commits
  • Aug 29 2019 14:09
    pushed to delors/opal
    2 commits
  • Aug 29 2019 13:36
    pushed to delors/opal
    2 commits
  • Aug 29 2019 13:18
    pushed to delors/opal
    10 commits
  • Aug 29 2019 13:16
    pushed to delors/opal
    More code duplication but should be slightly faster (compare)
  • Aug 29 2019 13:06
    pushed to delors/opal
    Prevent useless partial results (compare)
  • Aug 28 2019 15:04
    pushed to delors/opal
    improved the performance of LongTrieSet by specializing the grow function (compare)
  • Aug 27 2019 13:47
    pushed to delors/opal
    4 commits
  • Aug 27 2019 13:24
    pushed to delors/opal
    Commit just for testing purposes (compare)
Michael Eichberg
@Delors
Yep
Alexander Gössl
@majestocx
Ok im working on this again so i have some more questions.
I try to use the MethodDescriptor object like this: MethodDescriptor("(): void").
I get this exception:
[info] java.lang.IllegalArgumentException: : void is not a valid field type descriptor
[info] at org.opalj.br.FieldType$.apply(Type.scala:361)
[info] at org.opalj.br.ReturnType$.apply(Type.scala:278)
[info] at org.opalj.br.MethodDescriptor$.apply(MethodDescriptor.scala:667)
Is my argument wrong?
I also tried this: MethodDescriptor("(java.lang.String[]): void") but i get java.lang.IllegalArgumentException: j is not a valid field type descriptor
I get same results with / instead of .
Michael Reif
@mreif

This is indeed wrong. When passing a String argument to a MethodDescriptor you have to pass it in JVM notation.

MethodDescriptor("([Ljava/lang/String;)V")

However, I would not recommend doing this because it's rather error-prone. You should use the other apply methods MethodDescriptor offers. Here are two examples:

MethodDescriptor(ArrayType(ObjectType.String), VoidType) // first parameter represents the parameter list, the second the return type MethodDescriptor(RefArray(LongType,ByteType,ObjectType.String), BooleanType) // a method with (long, byte, String): boolean

You can find more example in OPAL's MethodDescriptor class itself
Alexander Gössl
@majestocx
ok i will give it a try
thanks for your answer
Alexander Gössl
@majestocx
it works :)
Michael Reif
@mreif
Good :-)
Alexander Gössl
@majestocx
@florian-kuebler I implemented your snippeet about the call graph. I have org.opalj.fpcf.EOptionP[org.opalj.br.DefinedMethod,org.opalj.br.fpcf.cg.properties.CallersProperty]. Is there a method to get from that to an svg?
Florian Kübler
@florian-kuebler
Unfortunately, the answer is no
Alexander Gössl
@majestocx
ok
Alexander Gössl
@majestocx
Is it possible to get the TAC from a class inside the jdk ? Like java/lang/String ?
Florian Kübler
@florian-kuebler
If the JDK is part of the project, it works just as for any other class. The File constant org.opalj.bytecode.RTJar, is the File of the current Java Runtime.
Alexander Gössl
@majestocx
Ok thanks for the information @florian-kuebler. I tried to get the TAC but method.body seems to be None. The jdk is part of the Analysis and libraryClassFilesAreInterfacesOnly is set to false.
Michael Eichberg
@Delors
How do you load the library? The method body should only be None if the method doesn’t have one (native or abstract) or if it is discarded while loading it. BTW libraryClassFilesAreInterfacesOnly actually doesn’t change how the classes are loaded - it basically reflects how the classes are expected to be loaded. That is, it might be possible that the “discarding" loader was used but libraryClassFilesAreInterfacesOnly is still false.
Alexander Gössl
@majestocx
Ok i will check wether the method is native / abstract. This is how the librarie is loaded:
val libraryClassFiles = Java9LibraryFramework.AllClassFiles(opalInit.libraries.map(new File(_)) :+ org.opalj.bytecode.RTJar )
Michael Eichberg
@Delors
ok…. Java9LibraryFramework kills the method bodies
you should use the “normal” Java9Framework
it is interessting that libraryClassFilesAreInterfacesOnly is false … there is clearly some issue somewhere!
Alexander Gössl
@majestocx
Ok now my Tests need some extra Memory but i still get the same exception:
nfo] - Load Project with jdk and libraryClassFilesAre not InterfacesOnly FAILED
[info] "java.util.NoSuchElementException: None.get
[info] at scala.None$.get(Option.scala:366)
[info] at scala.None$.get(Option.scala:364)
[info] at org.opalj.tac.TACNaive$.apply(TACNaive.scala:70)
[info] at org.opalj.tac.ToTxt$.$anonfun$apply$9(ToTxt.scala:319)
[info] at scala.Option.getOrElse(Option.scala:138)
[info] at org.opalj.tac.ToTxt$.apply(ToTxt.scala:318)
[info] at opal.extension.vscode.OPALProject.$anonfun$getTacForClass$2(OPALProject.scala:124)
[info] at opal.extension.vscode.OPALProject.$anonfun$getTacForClass$2$adapted(OPALProject.scala:116)
[info] at org.opalj.collection.immutable.RefArray.foreach(RefArray.scala:289)
[info] at opal.extension.vscode.OPALProject.getTacForClass(OPALProject.scala:116)
Michael Eichberg
@Delors
First - have you tried using the AI based variant of the TAC instead of TACNaive? If the first one works, it is a bug in the latter :-)
If does work with TACAI but doesn’t work with TACNaive can you tell which class causes the troubles?
Alexander Gössl
@majestocx
Unfortunately it does not work with both options...
The error occurres at the TACNaive.scala at Line 70: val code = method.body.get (body is None)
Michael Eichberg
@Delors
Hi Everybody, I just wanted to let you know that I just updated all subprojects to make them compatible with Java 11. That is, all projects can now be compiled and run on Java 11. Furthermore, Hermes (Core) doesn’t have any relevant JavaFX dependencies anymore. Given that all JavaFX libs are pulled from Maven, it should now be possible to build all of OPAL even in headless settings. (Of course, executing the Hermes UI requires a proper/complete JavaFX installation.)
BTW If you want to run the Hermes UI, don’t use the Eclipse J9 JVM - at least I didn’t get it working.
Ben Hermann
@bhermann
That is great! Especially the headless option is very helpful for me! Thank you!
mariotrageser
@mariotrageser
Bildschirmfoto 2019-05-04 um 14.33.55.png
Michael Eichberg
@Delors
Hi - such a bug may happen if you use the same (fully qualified) class name in different projects.
mariotrageser
@mariotrageser
When IntelliJ tries to compile OPAL, I get this error since one week.
I have to remove the sub modules „Demos“ and „Validate“ from the project every time. They seem to be duplicates of „OPAL-Developer Tools“ and „OPAL-Validate“. Did you change the project structure in the last days?
Michael Eichberg
@Delors
yes I did
you may have to reimport everything
mariotrageser
@mariotrageser
Ok, I try to do so. Thank you
Are Demos and Validate the new projects, which replace the two others?
Michael Eichberg
@Delors
Not exactly
Demos exists “forever"
OPAL-Validate => Validate
mariotrageser
@mariotrageser
I meant Tools and OPAL-Developer Tools. So „OPAL-Developer Tools“ should also no longer exist?
Michael Eichberg
@Delors
OPAL-DeveloperTools => Tools
Yes
mariotrageser
@mariotrageser
I had to remove them manually, but now everything works. Thank you
Javor Nikolov
@bubbazz
there is a way to get the current program counter from the classes "SimpleBranchInstruction" and "LOOKUPSWITCH".
Michael Eichberg
@Delors
No - this information is generally only implicitly available. If you use Code’s iterate and foreach methods you are always provided with the current pc. Does this help? If not, can you provide us with a short sample?
ewontfix
@ewontfix
Is there an easy way to get all primitive expressions (expressions which don't contain subexpressions) which occur in a TAC Stmt? Stmt.forallSubExpression seems to be a bit overkill for this use case.
Michael Eichberg
@Delors
In general, the TAC code is flat; i.e., a statement’s expressions are either Vars or Consts - that’s it. (OPAL has the ability to represent nested (sub) expressions, but this feature is reserved for future usage related to decompling code.) Hence, Stmt.forallSubExpression combined with a simple match over the two mentioned types of expressions should be sufficient in most to all cases. Does this help?
ewontfix
@ewontfix
Yes, thanks. My Code already works with Stmt.forallSubExpressions. It just takes somewhat longer than expected to execute and I guessed unnecessary exploring of a lot of intermediate expressions might be the cause. But if expressions are already flat, there is probably another cause.