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
java.lang.InstantiationError when upgrading to Kotlin 1.7 #832
Comments
Same behaviour for simple |
Probably related: Getting the following error
Where code is:
and mock is:
Worked well in 1.6.10 / Java 17 with Mockk 1.12.2 |
I can confirm the problem as were having it too |
@ygaller it seems related to |
I have a same problem. (kotlin 1.7.0 & mockk 1.12.4)
|
Meaningless bump. This is most definitely related to |
We encounter the same issue with sealed classes and interfaces with version |
Any update for this issue, is there any workaround? |
Thanks for the suggestion, here a reproduction project: https://github.com/ThanksForAllTheFish/mockk832 |
Same to me... |
mockk/mockk#832 - som igjen feiler tester i prefill.
Apparently something changed with sealed classes in 1.7. However, I couldn't find anything in the release notes: the only mention of sealed classes is that non-exhaustive sealed hierarchies now trigger an error rather than a warning. |
Apparently Kotlin 1.7 in combination with Java 17 uses Java sealed classes. I compiled the following code with Kotlin 1.6 and 1.7 and then decompiled. sealed class Foo
class Bar : Foo() Kotlin 1.7 decompiled: public abstract sealed class Foo permits Bar {
private Foo() {
}
// $FF: synthetic method
public Foo(DefaultConstructorMarker $constructor_marker) {
this();
}
} Kotlin 1.6 decompiled: public abstract class Foo {
private Foo() {
}
// $FF: synthetic method
public Foo(DefaultConstructorMarker $constructor_marker) {
this();
}
} |
Right, Java 17 added a sealed class feature, and I guess Kotlin is supporting that in the bytecode for Kotlin sealed classes when using Kotlin 1.7 with Java 17. |
…mockk: mockk/mockk#832 - som igjen feiler tester i prefill-appen
…bel for mockk: mockk/mockk#832 - som igjen feiler tester i prefill-appen" This reverts commit 63c536c.
…bel for mockk: mockk/mockk#832 - som igjen feiler tester i prefill-appen" This reverts commit 63c536c.
I can work around it in some cases by mocking a specific implementation class instead of the sealed interface itself. However that does not work if the sealed class or interface is a "returns" value. Is there any news if mocking sealed classes and interfaces will be possible again later? |
I've locally tried a to solve it in a hacky way to see if it would work, by adding an extra if statement to
runCatching {
if (clazz.isSealed) {
return subclass(clazz.permittedSubclasses.first() as Class<T>, interfaces)
}
} This does work, but arbitrarily picking the first permitted sub class feels like an ugly hack. And this only works when building MockK with Java 17. |
It seems a Kotlin-1.7 support merged into the master, not sure if it fixed this issue. |
@Raibaz |
In my case is failing even with sealed classes returned by the mocked method, so the workaround to mock an implementation of the sealed class is not working, even when I'm returning the mock with that implementation. |
Since Java 9, you can use Runtime.version() println(Runtime.version()) // 17.0.1+12-LTS
println(Runtime.version().feature()) // 17 And before Java 9 : println(System.getProperty("java.specification.version")) // 17 |
Great ideas, would you be able to give them a go?
|
Attempt to fix mockk#832 by making `ObjenesisInstantiator` work with a `KClass`.
Tried but the test workflows are not so automated for first-time contributors 😉 |
Attempt to fix mockk#832 by making `ObjenesisInstantiator` work with a `KClass`.
Attempt to fix mockk#832 by making `ObjenesisInstantiator` work with a `KClass`.
Good point! I forgot. As a workaround you can create a PR in your own fork, from the branch against master. |
Hey, I see from stuebingerb#1 that all of the tests now pass, is this good to merge and be included in a new MockK release? My projects are waiting to upgrade to Kotlin 1.7 due to this mockk failure. |
I am also waiting a new release to upgrade my project to Kotlin 1.7. |
Hey sorry about the delay, releasing 1.12.8 now. |
But the code has not been merged in the main repo, right? The new release do not include the fixing code. |
#916 attempts to fix the issue & hasn't been merged yet. |
What's holding up the merge? Can it be included in |
Updated to 1.12.8, still failed https://github.com/hantsy/mockk-issue832/actions/runs/3065819014/jobs/4950308126#step:4:42 |
Done, v1.13.2 is out :) |
1.13.2 only partly solves the issue: // given the following sealed class
sealed class Foo
class FooSub : Foo()
// and the following class with a method that has function with a sealed class as parameter
class Bar {
fun fooParam(foo: Foo): Int = 42
}
// then the following now works
val foo : Foo = mockk() // Fixed since 1.13.2
// but when using any() where a sealed class is expected the issue still persists
val bar: Bar = mockk()
every { bar.fooParam(any()) } returns 1 // throws InstantiationError This can probably be fixed in JvmSignatureValueGenerator with the same trick: Passing the first subclass to |
@cliffred that matches what I am seeing locally with 1.13.2. I wonder if this should be re-opened or a more specific issue raised? |
Sealed class issue got fixed for me with 1.13.2 |
Java 17 + Kotlin 1.7 + Mockk 1.12.4/Spring Mockk 3.1.1
It occurred whens using
coEvery{}
to do some stub, which returns aUpdateAccountResult.Success()
.Here
UpdateAccountResult
is asealed class
, it has some detailed result subclass/sub data classes.And
UpdateAccountResult
extends from a base abstract class like this.These codes are working well with Kotlin 1.6.21.
The text was updated successfully, but these errors were encountered: