Skip to content

Conversation

@knewbury01
Copy link

This contribution is a patch adapter tool
that transforms software patches into hotfixes
that can be used by Java Agents.
The tool categorizes changes in patches as compliant or
not with respect to the JVMTI standards for redefinition.
If non-compliant changes exist, the tool uses Soot
to analyze and transform those classes.

Signed-off-by: Kristen Newbury [email protected]

@andrewcraik
Copy link
Contributor

Can you explain why you have binary class files in the commit?

@andrewcraik
Copy link
Contributor

@DanHeidinga / @mstoodle I think this is a big enough chunk of code that we will likely need a CQ

This contribution is a patch adapter tool
that transforms software patches into hotfixes
that can be used by Java Agents
without throwing unsupportedOperationExceptions

Signed-off-by: Kristen Newbury <[email protected]>
@knewbury01
Copy link
Author

Can you explain why you have binary class files in the commit?

Fixed.

Previously added classfiles that are required in testing setup. Now have removed all classfiles, and, project includes script to build those, pre Maven regular test cycle.
The reason this extra setup is required is due to the fact that the patch adapter test setup required two variants of the same class, by definition of a patch to test upon, which requires minor extra setup compared to what can naturally be supported in a Maven project structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants