-
Notifications
You must be signed in to change notification settings - Fork 583
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
powermock 2.0.9 fails due to java.lang.RuntimeException: class is frozen #1154
Comments
The following change could help workaround the issue, I'm about to make a PR
|
romanatazuldotcom
added a commit
to romanatazuldotcom/powermock
that referenced
this issue
Apr 7, 2023
…n before its constructor transformed
romanatazuldotcom
added a commit
to romanatazuldotcom/powermock
that referenced
this issue
Apr 7, 2023
…n before its constructor transformed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
pom.xml depdendencies
Reproducer test case
Stack trace
This seems to be related to be38fb2
There could be cases with classes having several levels of class nesting. Looks like the issue appears with the innermost nested class loaded before its outer class is mocked e.g. in case the sibling class of the outer class also uses the innermost nested class. In the reproducer test case below, the nested class Foo has a Bar.Baz as an argument. Mocking the class Foo causes a side effect of loading a Bar.Baz. Apparently, bytebuddy retrieves a method 'foo' arguments list which causes JVM to load the types of arguments.
Looks like a class load makes Bar.Baz 'frozen' in terms of javassist library, so when the Bar is processed with the logic introduced at be38fb2, the RuntimeException is thrown by javassist.
The text was updated successfully, but these errors were encountered: