soot-oss / sootup Goto Github PK

resources:
https://www.javaworld.com/article/3184029/java-language/java-9s-other-new-enhancements-part-4-multi-release-jar-files.html
https://www.baeldung.com/java-multi-release-jar

TODO

depends on #185 (java9 module loading)

Parameter: newest supported Java Version

• ignore java versions <9 (according to spec)
• select newest version lower equals given parameter down to base version

nice2have:

• list existing version variants of a module
• above list merged across all user specified modules

• Please branch from the develop branch and make sure your branch merged all changes from develop before submitting
• Please write description of the pull request
• Please link the associated Issue https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue
• Please keep the pull request as small as possible
• Please keep the pull request with one intention (one feature)
• Please commit stepwise
• Please communicate with other people who are currently working on different branches before refactoring
• Unless it is a working in progress pull request, please ensure all tests pass before you submit it

Use magic bytes like we do in the old Soot to identify apk, zip, jar, etc. instead of relying on the file ending.

Since number of classes is changing all the time, we used lower bounds for classes that need to be found. This is really dirty and we certainly need a better solution here. Probably some precompiled classes in the test resources.

This can be copied from the original Soot's pom file. And automatically readded for all existent files. The copyright notice has to be adapted for all current authors (easy just me and Andreas).

Like the tests provided by Rajat, we should use the old Soot to jimplify the Dacapo benchmark and compare the results with the jimplification of the new Soot, to ensure nothing was broken.

@anddann can you look why tests for java8 and java9 both are executed in test steps on the build server?

under either

mvn test -Dgroups="categories.Java8Test"

or

mvn test -Dgroups="categories.Java9Test"

all tests will be executed.

The current configuration of the checkstyle plugin in the pom.xml reports different results when using mvn clean compile, mvn checkstyle:check, or mvn checkstyle:checkstyle

Since MethodRefs have been removed from the project, the documentation and comments in the code should be updated accordingly. As an example, one such instance can be found here.

Since we want FutureSoot to support multiple languages. Right now the signature is only targeting Java and we should make this more extensible.

class name with ClassSignature, etc.

see de.upb.soot.signatures.

https://docs.oracle.com/javase/9/docs/api/java/util/jar/JarFile.html

Using the Class JarFile allows reading Manifest entries and supporting multi-release jar files #50

Like in the old Soot, we can run Dacapo before and after Soot hast jimplified and written back to bytecode and compare the results to check if the jimplification and front-/backend is working correctly.

Please change this in class JInstanceFieldRef and JStaticFieldRef

for example: change public JStaticFieldRef(SootField field) to public JStaticFieldRef(IView view, FieldSignature field)

• implement getField() methods like AbstractInvokeExpr.getMethod(), always query the field from the class in view.

• delete the setters and make these two classes immutable.

please change this in jimple branch

Jimple statements can be checked for structural equality by calling the EquivTo. equivTo method with another statement. The implementation is a tree traversal that checks the equivalence of each subtree. Nodes can be Locals or Values (maybe more). Currently, the structural equivalence of two locals is decided by checking their type and name for equality. This should further be the standard behavior.
Another equivTo method that takes a Comparator (or a similar callback) should be implemented to allow for arbitrary comparisons, e.g., only type of locals.

Please use TypeSignature

@ericbodden @bhermann @mbenz89 @anddann @swissiety
Hi everyone,

our new WHB-student Christian just suggested that we should build future soot in kotlin, which is 100% java-compatible, with simpler syntax and easier to be maintained than java.
Here are studies he found about better code quality with kotlin
https://dl.acm.org/citation.cfm?id=3267186
https://arxiv.org/abs/1808.00025

What do you think?

Branch: feature/parallel-jimplification

A large number of classes in this project implement Object.clone(), especially the ones related to Jimple (such as JEqExp). However, it seems the only implementation that is used directly in the project is the one from PositionInfo.

The book Effective Java by Joshua Bloch (available here), who led the design of various Java features, gives some advice on the flaws of the method and its associated interface Cloneable starting on page 54 (Item 11: Override clone judiciously).

Hence I'm wondering why we have these implementations. If it turns out that there is no use case for them, I would propose to remove these implementations. Otherwise, depending on the use case, we could evaluate using a different mechanism with saner semantics.

We should create a backport for the MethodHandle/VarHandle feature from Soot into SootReloaded soot-oss/soot#1109

With PR #89, the Utils class will be containing lots of helper functions. Not all of them relate to each other, so the class should be broken apart into groups of related functions to aid discoverability.

@anddann
the method JavaClassSignature getClassSignature(final String fullyQualifiedClassName) always replace $ with dot when the given name is the name of an inner class. For example, A$B will be replaced by A.B.
This is different than the java bytecode-style name in old soot . Do you want this intentionally?

In the wala branch, some tests I'm writing are failing, for example BinaryOpInstructionConversionTest.testAddDouble.

This is because the converted Jimple contains an instruction $i0 = $d0 + $d1 where $i0 is an int. This is invalid.

This issue doesn't seem to be limited to just addition and also breaks other tests in BinaryOpInstructionConversionTest.java.

Existing:

• CHA

Todos:

• RTA
• VTA
• SPARK