New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ByteBuddy to instrument classes instead Javassist #727

Open
thekingnothing opened this Issue Dec 1, 2016 · 42 comments

Comments

Projects
None yet
@thekingnothing
Member

thekingnothing commented Dec 1, 2016

The main issue with Javassist it's that it read classes from disk before instrumenting. Such behaviour breaks compatibility with other tools which are instrumenting classes (see discussion jacoco/jacoco#51)

ByteBuddy could help us to resolve the issue and supporting online Jacoco Instrumenting.

ByteBudy agent has to be used for implementation of powermock-agent

@thekingnothing thekingnothing added this to the PowerMock 2.0.0 milestone Dec 1, 2016

@thekingnothing thekingnothing referenced this issue Dec 1, 2016

Closed

PowerMock 2 Roadmap #725

6 of 6 tasks complete

thekingnothing added a commit that referenced this issue Mar 18, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockClassLoader  - extract Javassist relative code to a new classes.

Signed-off-by: Arthur Zagretdinov <arthur.zagretdinov@outlook.com>

thekingnothing added a commit that referenced this issue Mar 18, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockClassLoader  - extract Javassist relative code to a new classes.

Signed-off-by: Arthur Zagretdinov <arthur.zagretdinov@outlook.com>

@thekingnothing thekingnothing self-assigned this Mar 18, 2017

thekingnothing added a commit that referenced this issue Apr 17, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockClassLoader  - extract Javassist relative code to a new classes.

thekingnothing added a commit that referenced this issue Apr 17, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockTransformer  - split transformer to set of small classes.

thekingnothing added a commit that referenced this issue Apr 17, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockClassLoader  - extract Javassist relative code to a new classes.

thekingnothing added a commit that referenced this issue Apr 17, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockTransformer  - split transformer to set of small classes.
@fabriziomieli

This comment has been minimized.

fabriziomieli commented Apr 26, 2017

Hi, When this is supposed to be ready?

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented Apr 26, 2017

@fabriziomieli

This comment has been minimized.

fabriziomieli commented Apr 27, 2017

Thank you very much

thekingnothing added a commit that referenced this issue May 1, 2017

#727 Use ByteBuddy to instrument classes instead Javassist
Implement modifiers related transformer

Signed-off-by: Arthur Zagretdinov <arthur.zagretdinov@outlook.com>

thekingnothing added a commit that referenced this issue May 1, 2017

#727 Use ByteBuddy to instrument classes instead Javassist
Implement static initialiser transformer

Signed-off-by: Arthur Zagretdinov <arthur.zagretdinov@outlook.com>

thekingnothing added a commit that referenced this issue Jun 18, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockClassLoader  - extract Javassist relative code to a new classes.

thekingnothing added a commit that referenced this issue Jun 18, 2017

Issue #727: Migrate from Javassist to ByteBuddy.
Refactoring MockTransformer  - split transformer to set of small classes.

thekingnothing added a commit that referenced this issue Jun 18, 2017

#727 Use ByteBuddy to instrument classes instead Javassist
Implement modifiers related transformer

Signed-off-by: Arthur Zagretdinov <arthur.zagretdinov@outlook.com>

thekingnothing added a commit that referenced this issue Jun 18, 2017

#727 Use ByteBuddy to instrument classes instead Javassist
Implement static initialiser transformer

Signed-off-by: Arthur Zagretdinov <arthur.zagretdinov@outlook.com>

thekingnothing added a commit that referenced this issue Jun 18, 2017

Implements #727 Use ByteBuddy to instrument classes instead Javassist
Fix issues after merging with master
@peter-janssen

This comment has been minimized.

peter-janssen commented Jul 7, 2017

Will you release this feature when it is ready or only as part of PowerMock 2.0?

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented Jul 7, 2017

I'm going to release it as part of PowerMock 2.0, because the change for ButyBuddy is close intertwined with clearing PowerMock from copy-pasted mockito code.

@peter-janssen

This comment has been minimized.

peter-janssen commented Jul 8, 2017

The 2.0 release looks quite big so I guess the earlier estimate of end of june (you did mean 2017, right?) will be pushed back quite a bit?

thekingnothing added a commit that referenced this issue Apr 29, 2018

thekingnothing added a commit that referenced this issue Apr 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- add ability to specify which bytecode modification framework to use.

thekingnothing added a commit that referenced this issue Apr 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- Fix all tests failed after last changes
@softcoder

This comment has been minimized.

softcoder commented May 1, 2018

Is there a build we can test these fixes? Please provide a link that would be awesome!

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented May 1, 2018

@softcoder the feature is still being developed and it's unready for testing. As soon as it will be ready I will merge changes to the release/2.x branch and drop a beta version release.

thekingnothing added a commit that referenced this issue May 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- Implement ByteBuddy TestClass transformer

thekingnothing added a commit that referenced this issue May 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- Fix test for ByteBuddy class loader.

thekingnothing added a commit that referenced this issue May 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- Add ability to  provide bytecode framework via environment variable, so Travis could run test against different frameworks.

thekingnothing added a commit that referenced this issue May 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- Fix issue with @PrepareOnlyThisForTest

thekingnothing added a commit that referenced this issue May 29, 2018

Fixes #727 Use ByteBuddy to instrument classes instead Javassist:
- Fix issue with @PrepareOnlyThisForTest
@softcoder

This comment has been minimized.

softcoder commented Jun 28, 2018

Will we be able to test this soon?

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented Jun 28, 2018

@softcoder I'm afraid that not earlier than in 2 months. I've got stuck with suppressing constructors and mocking new call. Previously, Javassit cared about the correct calculation of the stack frame. Now, I have to do it by myself.

@IslamSalah

This comment has been minimized.

IslamSalah commented Aug 28, 2018

Has the release plan been updated?

@benken-parasoft

This comment has been minimized.

benken-parasoft commented Sep 7, 2018

Is there an ETA for a 2.0.0 release? If there are more unforeseen delays, perhaps a newer beta can be published to maven central? The last beta that was published (beta.5) is almost a year old.

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented Sep 12, 2018

Update: the current situation is the following: I prepared RC with ByteBuddy and dropped it, however later I found out that all tests were running only against Javassist implementation. After I fixed build script I saw that my implementation for a constructor and new call mocking worked only in basic cases.

I am trying to implement a general solution which will work in most cases. The main issue I have now - ByteBuddy does not provide any API to insert conditions in bytecode. As a result, I have to implement everything by myself: calculating stack, local variable and so on.

@benken-parasoft, the last beta was released last May.
https://bintray.com/powermock/generic/powermock-development/powermock-2.0.0-beta.11
However, this beta has full Mockito 2.0 support and even have ByteBuddy implementation which does not work correctly except very basic cases.

I don't have any ETA for 2.0.0 release for now, as the issue I have now it's a pretty hard and working less than 4-5 hours per I moving very slow.

@benken-parasoft

This comment has been minimized.

benken-parasoft commented Sep 12, 2018

Thanks for the update. For background, enterprise users like myself are moving ahead with newer java releases which now release every six months. For existing unit test bases that use powermock, we have to either switch to 2.x or hold our entire unit test bases to older java versions.

the last beta was released last May

Thanks for the clarification. I only found the source tag but not any released binaries. Up until now, I've always pulled powermock releases from maven central, including the latest 1.7.4 release from April. Are you no longer releasing binaries to maven central for 2.x? Was this intentional or an oversight? Or should users stop using maven central and use the maven repository from bintray instead?

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented Oct 7, 2018

@benken-parasoft,

I only found the source tag but not any released binaries. Up until now, I've always pulled powermock releases from maven central, including the latest 1.7.4 release from April. Are you no longer releasing binaries to maven central for 2.x? Was this intentional or an oversight?

It was done intentionally as I don't want to span Maven Central with a lot of beta version. PowerMocks migrated to continue delivery, so it means that each pull request merged to release branches is being published to a repository as an artifact. However, I understood that could development PowerMock 2.0 could take a lot time (not so many as it already has taken), I decided to split beta release to Bintray and GA release to maven central.

@thekingnothing

This comment has been minimized.

Member

thekingnothing commented Oct 24, 2018

I'm excluding this feature from PowerMock 2.0.0 as working on it took to many time and I'm not able to finish it in near future. I will release PowerMock 2.0.0 with all changes and full supporting Mockito 2.x and then will continue work on this feature as a part of PowerMock 3.x where I will drop supporting Java less than 1.8

@Tibor17

This comment has been minimized.

Tibor17 commented Oct 24, 2018

@thekingnothing
I respect your decision.
I think here your work is to use very low level bytecode instructions. I saw similar work in JaCoCo project. So. If you involved committers from JaCoCo, their experiences would be beneficial and you would have more spare time for yourself.

thekingnothing added a commit that referenced this issue Oct 24, 2018

[ci maven-central-release] PowerMock 2.0 Release without ByteBuddy (#948
)

Preparing PowerMock 2.0 Release without ByteBuddy 

* Remove all ByteBuddy Classloader code (#727)
* Fix tests
* Update Libraries

@thekingnothing thekingnothing removed this from In progress in PowerMock 2.x Oct 24, 2018

@benken-parasoft

This comment has been minimized.

benken-parasoft commented Nov 5, 2018

@thekingnothing, I notice ByteBuddy changes backed out as part of PR 948. Then I saw PR 910 mentioned in the release notes 2.0.0 RC1 but I assume this is just referring to what you had backed out. However, I still might not be understanding these changes correctly. Can you clarify what is or isn't being included with respect to ByteBuddy for the 2.0.0 release?

I am primarily concerned about java version support. My organization needs to be able to support new Java releases as they come out, which is now every six months. Based on my observations, this appears to depend on which version of what byte code library being used, ByteBuddy vs Javassist. For example, I seemed to be able to do static mocking in Java 11 with PowerMock 2.0.0 beta 11 with Mockito 2.23 and ByteBuddy 1.9. So, if PowerMock 2.0.0 switches back to using Javassist then will static mocking no long work in java > 8 again? To support new java, such as java 11, will I be able to switch to the 2.0.0 release or should I should stay on beta 11 or use later a 3.0 snapshot with preliminary ByteBuddy support re-introduced?

@benken-parasoft

This comment has been minimized.

benken-parasoft commented Nov 6, 2018

I am primarily concerned about java version support.

With PowerMock 22 using Javassist again, it looks like PowerMock would only work with Java 9 but not 10 or 11. At least, the pom.xml for PowerMock 2.0.0-RC.2 shows a dependency on Javassist 3.22.0-GA which looks to support Java 9. Perhaps it be possible to use PowerMock with Javassist 3.24.0-GA for Java 11 support instead? Previously, with PowerMock 2.0.0 beta 11, I was able to use ByteBuddy 1.9 for Java 11 support.

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