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)
kebiro
@kebiro

Hello,

we had a little chat about this before: there is possibly a bug in OPAL regarding an escaping backslash. It seems to escape them before outputting the text. I'll provide an example.

image.png
This is the original string in String.java
In String.classit looks like this:
image.png
Alexander Gössl
@majestocx
ok i got my method working thanks all for your help!
kebiro
@kebiro
However, the TAC output looks like this:
image.png
There is only a single backslash left, hence the following " is escaped, so until another " appears everything will be seen as a string.
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