realdadfish

realdadfish

Freelance Android Developer

Member Since 11 years ago

Germany

Experience Points
24
follower
Lessons Completed
0
follow
Lessons Completed
103
stars
Best Reply Awards
78
repos

36 contributions in the last year

Pinned
⚡ This is a fork of the NodeJS-driven Dashboard of the free Dropbox alternative SparkleShare
⚡ Maven repository
⚡ monotone support for indefero
⚡ a wiki compiler
⚡ A jQuery plugin for creating a cross device(tough optimized for the iPad and iPhone) pageflipper, suports both touch and mouse events for flipping trough the pages.
⚡ The ownCloud Android App
Activity
Oct
18
5 days ago
Activity icon
issue

realdadfish issue comment robolectric/robolectric

realdadfish
realdadfish

Jetpack Compose Screenshot Tooling

I'm using Robolectric 4.5.1 to test my Jetpack Compose UI. Due to the nature of Compose Testing, one does not get access to a full-blown "view-alike" tree, but only a "semantic tree", that is built alongside with the actual visible elements. This semantic tree is not only used for testing, but also accessibility support, so testing in Compose is a little more like UIAutomator testing (in comparison to the whitebox-alike instrumented Espresso Testing what one is used to).

The semantic tree, as the name suggests, does not hold any visual information about what is seen on screen, no colors, no icons, nothing. So to properly test a Compose implementation, one has to reside on screen snapshotting, e.g. by utilizing SemanticsNodeInteraction.captureToImage(). This internally uses PixelCopy.request() to create an offscreen buffer of what's drawn on screen, after a draw call happened.

However, when called from Robolectric, thisPixelCopy is never triggered, as it fails to register the "first" draw on screen, i.e. drawDone is never true (tested with sdk = 28 and sdk = 29):

 val decorView = windowToCapture.decorView
    handler.post {
        if (Build.VERSION.SDK_INT >= 29 && decorView.isHardwareAccelerated) {
            FrameCommitCallbackHelper.registerFrameCommitCallback(decorView.viewTreeObserver) {
                drawDone = true
            }
        } else {
            decorView.viewTreeObserver.addOnDrawListener(object : ViewTreeObserver.OnDrawListener {
                var handled = false
                override fun onDraw() {
                    if (!handled) {
                        handled = true
                        handler.post {
                            drawDone = true
                            decorView.viewTreeObserver.removeOnDrawListener(this)
                        }
                    }
                }
            })
        }
        decorView.invalidate()
    }

(WindowCapture.android.kt from androidx.compose.ui:ui-test:1.0.1)

On previous occasions I tried to use PixelCopy myself to capture screen contents within Robolectric, which always resulted in a black screen.

Is there any support for screenshot making on the horizon for Robolectric or is this impossible to do?

realdadfish
realdadfish

Yes, this is exactly the issue.

Oct
8
2 weeks ago
Activity icon
issue

realdadfish issue google/dagger

realdadfish
realdadfish

Make ViewModelComponent accessible via an EntryPoint

Right now it is possible to create and access dependencies in UI tests via EntryPoints for pretty much every component. If one needs a dependency from ActivityRetainedComponent, an EntryPoint targeting ActivityComponent and FragmentComponent does the trick, because both components inherit the dependencies from ActivityRetainedComponent (and SingletonComponent, which however can be injected directly in the @HiltAndroidTest class).

Where this falls short is when one tries to access ViewModelComponent. Reason for this is because reference of the generated component in HiltViewModelFactory is never stored anywhere, so it becomes invisible to the outside world.

I understand that to let this work with the same mechanism like Fragments and Activitys, Hilt would have to generate a custom base instance of the ViewModel implementation and let this implement GeneratedComponentManager<ViewModelComponent>. Why hasn't this taken into consideration? Shouldn't the class that shares the lifetime with the component being able to hold an instance of it?

Right now, the only workaround is to make dependencies test-accessible in your ViewModel and let your test grab the original ViewModel instance from the factory:

@HiltViewModel
internal class MyViewModel @Inject constructor(
    @VisibleForTesting internal val stateHandle: SavedStateHandle
) : CustomBaseViewModel<Foo>() { ... }

// ...

private val viewModel: MyViewModel by lazy {
    var viewModel: MyViewModel? = null
    fragmentRule.fragmentScenario?.onFragment { fragment ->
        viewModel = ViewModelProvider(fragment)[MyViewModel::class.java]
    }
    requireNotNull(viewModel) { "Fragment is not yet initialized" }
}


@Test
fun myTest() {
    fragmentRule.launch()
    // do stubbing / verification
    viewModel.stateHandle.get(...)
}
Oct
7
2 weeks ago
Activity icon
issue

realdadfish issue robolectric/robolectric

realdadfish
realdadfish

Jetpack Compose Screenshot Tooling

I'm using Robolectric 4.5.1 to test my Jetpack Compose UI. Due to the nature of Compose Testing, one does not get access to a full-blown "view-alike" tree, but only a "semantic tree", that is built alongside with the actual visible elements. This semantic tree is not only used for testing, but also accessibility support, so testing in Compose is a little more like UIAutomator testing (in comparison to the whitebox-alike instrumented Espresso Testing what one is used to).

The semantic tree, as the name suggests, does not hold any visual information about what is seen on screen, no colors, no icons, nothing. So to properly test a Compose implementation, one has to reside on screen snapshotting, e.g. by utilizing SemanticsNodeInteraction.captureToImage(). This internally uses PixelCopy.request() to create an offscreen buffer of what's drawn on screen, after a draw call happened.

However, when called from Robolectric, thisPixelCopy is never triggered, as it fails to register the "first" draw on screen, i.e. drawDone is never true (tested with sdk = 28 and sdk = 29):

 val decorView = windowToCapture.decorView
    handler.post {
        if (Build.VERSION.SDK_INT >= 29 && decorView.isHardwareAccelerated) {
            FrameCommitCallbackHelper.registerFrameCommitCallback(decorView.viewTreeObserver) {
                drawDone = true
            }
        } else {
            decorView.viewTreeObserver.addOnDrawListener(object : ViewTreeObserver.OnDrawListener {
                var handled = false
                override fun onDraw() {
                    if (!handled) {
                        handled = true
                        handler.post {
                            drawDone = true
                            decorView.viewTreeObserver.removeOnDrawListener(this)
                        }
                    }
                }
            })
        }
        decorView.invalidate()
    }

(WindowCapture.android.kt from androidx.compose.ui:ui-test:1.0.1)

On previous occasions I tried to use PixelCopy myself to capture screen contents within Robolectric, which always resulted in a black screen.

Is there any support for screenshot making on the horizon for Robolectric or is this impossible to do?

Sep
22
1 month ago
Activity icon
issue

realdadfish issue allure-framework/allure-gradle

realdadfish
realdadfish

JCenter sundown

While now put on "read-only for the community", Bintray's jcenter is no longer a viable option to publish / host artifacts. (https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/)

It would be great if the project could therefor offer an alternative hosting, e.g. mavenCentral.

Thanks!

Activity icon
issue

realdadfish issue comment allure-framework/allure-gradle

realdadfish
realdadfish

JCenter sundown

While now put on "read-only for the community", Bintray's jcenter is no longer a viable option to publish / host artifacts. (https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/)

It would be great if the project could therefor offer an alternative hosting, e.g. mavenCentral.

Thanks!

realdadfish
realdadfish

Ok, apparently this is no longer an issue then. Thanks for the heads-up!

Sep
20
1 month ago
Activity icon
issue

realdadfish issue comment mockito/mockito

realdadfish
realdadfish

Introduce a BOM for Mockito's artifacts (closes #2321)

See discussion in #2321

realdadfish
realdadfish

Hey @TimvdLippe, what's the status of this? :-)

Sep
10
1 month ago
Activity icon
issue

realdadfish issue comment mockk/mockk

realdadfish
realdadfish

kotlin.KotlinNullPointerException error when I try to use any() method on a value class parameter

When I try to use any() method on a parameter with a value class as type, I have kotlin.KotlinNullPointerException error.

Expected Behavior

The test should run correctly and the mock can intercept all instance of the value class parameter.

Current Behavior

Generate a kotlin.KotlinNullPointerException error on test execution I don't have the issue if I replace the value class with data class and I don't have the issue if I replace the any() call by a explicit instance of the value class.

Steps to Reproduce

See the code below.

Context

  • MockK version: 1.12.0
  • OS: MacOs 11.5.2 (20G95)
  • Kotlin version: 1.5.21, 1.5.30
  • JDK version: OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
  • JUnit version: 5.6.2 (if I belived the depencies tree in IntelliJ)
  • Kotest version : 4.6.1, 4.6.2
  • Type of test: unit test

Failure Logs

Please include any relevant log snippets or files here.

Stack trace

Test failed
kotlin.KotlinNullPointerException
	at io.mockk.impl.recording.states.RecordingState.matcher(RecordingState.kt:53)
	at io.mockk.impl.recording.CommonCallRecorder.matcher(CommonCallRecorder.kt:52)
	at org.test.HelloTest$1$1$1.invoke(HelloTest.kt:22)
	at org.test.HelloTest$1$1$1.invoke(HelloTest.kt:12)
	at io.mockk.impl.eval.RecordedBlockEvaluator$record$block$1.invoke(RecordedBlockEvaluator.kt:25)
	at io.mockk.impl.eval.RecordedBlockEvaluator$enhanceWithRethrow$1.invoke(RecordedBlockEvaluator.kt:78)
	at io.mockk.impl.recording.JvmAutoHinter.autoHint(JvmAutoHinter.kt:23)
	at io.mockk.impl.eval.RecordedBlockEvaluator.record(RecordedBlockEvaluator.kt:40)
	at io.mockk.impl.eval.EveryBlockEvaluator.every(EveryBlockEvaluator.kt:30)
	at io.mockk.MockKDsl.internalEvery(API.kt:92)
	at io.mockk.MockKKt.every(MockK.kt:98)
	at org.test.HelloTest$1$1.invokeSuspend(HelloTest.kt:12)
	at org.test.HelloTest$1$1.invoke(HelloTest.kt)
	at org.test.HelloTest$1$1.invoke(HelloTest.kt)
	at io.kotest.core.internal.ExecutionsKt$executeWithBehaviours$2$1.invokeSuspend(executions.kt:13)
	at io.kotest.core.internal.ExecutionsKt$executeWithBehaviours$2$1.invoke(executions.kt)
	at io.kotest.core.internal.ExecutionsKt$executeWithBehaviours$2$1.invoke(executions.kt)
	at io.kotest.core.internal.ExecutionsKt.wrapTestWithGlobalAssert(executions.kt:39)
	at io.kotest.core.internal.ExecutionsKt.access$wrapTestWithGlobalAssert(executions.kt:1)
	at io.kotest.core.internal.ExecutionsKt$executeWithBehaviours$2.invokeSuspend(executions.kt:12)
	at io.kotest.core.internal.ExecutionsKt$executeWithBehaviours$2.invoke(executions.kt)
	at io.kotest.core.internal.ExecutionsKt$executeWithBehaviours$2.invoke(executions.kt)
	at io.kotest.core.internal.ExecutionsKt$wrapTestWithAssertionModeCheck$2.invokeSuspend(executions.kt:25)
	at io.kotest.core.internal.ExecutionsKt$wrapTestWithAssertionModeCheck$2.invoke(executions.kt)
	at io.kotest.core.internal.ExecutionsKt$wrapTestWithAssertionModeCheck$2.invoke(executions.kt)
	at io.kotest.core.internal.AssertionsCheckKt.executeWithAssertionsCheck(assertionsCheck.kt:25)
	at io.kotest.core.internal.ExecutionsKt.wrapTestWithAssertionModeCheck(executions.kt:24)
	at io.kotest.core.internal.ExecutionsKt.executeWithBehaviours(executions.kt:11)
	at io.kotest.core.internal.TestCaseExecutor$executeInScope$2.invokeSuspend(TestCaseExecutor.kt:268)
	at io.kotest.core.internal.TestCaseExecutor$executeInScope$2.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeInScope$2.invoke(TestCaseExecutor.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:89)
	at kotlinx.coroutines.CoroutineScopeKt.coroutineScope(CoroutineScope.kt:264)
	at io.kotest.core.internal.TestCaseExecutor.executeInScope(TestCaseExecutor.kt:262)
	at io.kotest.core.internal.TestCaseExecutor.access$executeInScope(TestCaseExecutor.kt:57)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3$1$1.invokeSuspend(TestCaseExecutor.kt:234)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3$1$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3$1$1.invoke(TestCaseExecutor.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:100)
	at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:148)
	at kotlinx.coroutines.TimeoutKt.withTimeout(Timeout.kt:44)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3$1.invokeSuspend(TestCaseExecutor.kt:233)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3$1.invoke(TestCaseExecutor.kt)
	at io.kotest.engine.ExecutorExecutionContext$executeWithTimeoutInterruption$4.invokeSuspend(ExecutorExecutionContext.kt:77)
	at io.kotest.engine.ExecutorExecutionContext$executeWithTimeoutInterruption$4.invoke(ExecutorExecutionContext.kt)
	at io.kotest.engine.ExecutorExecutionContext$executeWithTimeoutInterruption$4.invoke(ExecutorExecutionContext.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:89)
	at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:165)
	at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
	at io.kotest.engine.ExecutorExecutionContext.executeWithTimeoutInterruption(ExecutorExecutionContext.kt:75)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3.invokeSuspend(TestCaseExecutor.kt:232)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1$3.invoke(TestCaseExecutor.kt)
	at io.kotest.mpp.ReplayKt.replay(replay.kt:18)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1.invokeSuspend(TestCaseExecutor.kt:227)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1$1.invoke(TestCaseExecutor.kt)
	at io.kotest.engine.ExecutorExecutionContext$executeWithTimeoutInterruption$4.invokeSuspend(ExecutorExecutionContext.kt:77)
	at io.kotest.engine.ExecutorExecutionContext$executeWithTimeoutInterruption$4.invoke(ExecutorExecutionContext.kt)
	at io.kotest.engine.ExecutorExecutionContext$executeWithTimeoutInterruption$4.invoke(ExecutorExecutionContext.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:89)
	at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:165)
	at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
	at io.kotest.engine.ExecutorExecutionContext.executeWithTimeoutInterruption(ExecutorExecutionContext.kt:75)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1.invokeSuspend(TestCaseExecutor.kt:220)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4$1.invoke(TestCaseExecutor.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:100)
	at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:148)
	at kotlinx.coroutines.TimeoutKt.withTimeout(Timeout.kt:44)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4.invokeSuspend(TestCaseExecutor.kt:219)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$executeAndWait$4.invoke(TestCaseExecutor.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:89)
	at kotlinx.coroutines.SupervisorKt.supervisorScope(Supervisor.kt:57)
	at io.kotest.core.internal.TestCaseExecutor.executeAndWait(TestCaseExecutor.kt:215)
	at io.kotest.core.internal.TestCaseExecutor.invokeTestCase(TestCaseExecutor.kt:184)
	at io.kotest.core.internal.TestCaseExecutor.executeActiveTest(TestCaseExecutor.kt:153)
	at io.kotest.core.internal.TestCaseExecutor.access$executeActiveTest(TestCaseExecutor.kt:57)
	at io.kotest.core.internal.TestCaseExecutor$intercept$innerExecute$1$1.invokeSuspend(TestCaseExecutor.kt:89)
	at io.kotest.core.internal.TestCaseExecutor$intercept$innerExecute$1$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$intercept$innerExecute$1$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor.executeIfEnabled(TestCaseExecutor.kt:117)
	at io.kotest.core.internal.TestCaseExecutor.access$executeIfEnabled(TestCaseExecutor.kt:57)
	at io.kotest.core.internal.TestCaseExecutor$intercept$innerExecute$1.invokeSuspend(TestCaseExecutor.kt:89)
	at io.kotest.core.internal.TestCaseExecutor$intercept$innerExecute$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor$intercept$innerExecute$1.invoke(TestCaseExecutor.kt)
	at io.kotest.core.internal.TestCaseExecutor.intercept(TestCaseExecutor.kt:103)
	at io.kotest.core.internal.TestCaseExecutor.execute(TestCaseExecutor.kt:69)
	at io.kotest.engine.spec.runners.SingleInstanceSpecRunner.runTest(SingleInstanceSpecRunner.kt:104)
	at io.kotest.engine.spec.runners.SingleInstanceSpecRunner.access$runTest(SingleInstanceSpecRunner.kt:34)
	at io.kotest.engine.spec.runners.SingleInstanceSpecRunner$execute$interceptAndRun$2$4.invokeSuspend(SingleInstanceSpecRunner.kt:57)
	at io.kotest.engine.spec.runners.SingleInstanceSpecRunner$execute$interceptAndRun$2$4.invoke(SingleInstanceSpecRunner.kt)
	at io.kotest.engine.spec.runners.SingleInstanceSpecRunner$execute$interceptAndRun$2$4.invoke(SingleInstanceSpecRunner.kt)
	at io.kotest.engine.launchers.SequentialTestLauncher$launch$3$1$1.invokeSuspend(SequentialTestLauncher.kt:22)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

Minimal reproducible code (the gist of this issue)

plugins {
    kotlin("jvm") version "1.5.21"
}

group = "org.example"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

dependencies {
    implementation(kotlin("stdlib"))
    testImplementation("io.kotest:kotest-runner-junit5:4.6.1")
    testImplementation("io.mockk:mockk:1.12.0")
}
package org.test

@JvmInline
value class Name(val value: String)

interface Printer {
    fun print(name: Name): String
}

class Hello(private val printer: Printer) {
    fun hello(name: String) {
        println(printer.print(Name(name)))
    }
}
package org.test

import io.kotest.core.spec.style.ShouldSpec
import io.mockk.every
import io.mockk.mockk

class HelloTest : ShouldSpec({
    val mockPrinter = mockk<Printer>()

    should("print message") {
        every { mockPrinter.print(any()) } returns "OK"

        val hello = Hello(mockPrinter)

        hello.hello("TEST")
    }

})
realdadfish
realdadfish

Identical issue / stacktrace with MockK 1.12.0 and Kotlin 1.5.30 w/ suspend functions:

@JvmInline
value class Bla(val value: String)

class Foo {
    suspend fun foo(arg: Bla) {
        delay(100)
        println(arg)
    }
}

class FooTest {
    @Test
    fun `should stub value class`() {
        val foo = mockk<Foo>()
        coEvery { foo.foo(any()) } coAnswers {}
    }
}
Sep
1
1 month ago
Activity icon
issue

realdadfish issue comment square/moshi

realdadfish
realdadfish

Moshi fails to process Kotlin 1.6 metadata

Caused by: java.lang.IllegalStateException: Could not parse metadata! This should only happen if you're using Kotlin <1.1.
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.readKotlinClassMetadata(KotlinPoetMetadata.kt:89)
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.toImmutableKmClass(KotlinPoetMetadata.kt:119)
	at com.squareup.moshi.kotlin.codegen.MoshiCachedClassInspector.toImmutableKmClass(MoshiCachedClassInspector.kt:37)
	at com.squareup.moshi.kotlin.codegen.MetadataKt.targetType(metadata.kt:139)
	at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.adapterGenerator(JsonClassCodegenProcessor.kt:148)

Project with reproduction test-moshi-kotlin16.zip

realdadfish
realdadfish

OK, I misread this then, I thought it was required to have it warn about it at all in 1.5 even. Thanks for the clarification!

Activity icon
issue

realdadfish issue comment square/moshi

realdadfish
realdadfish

Moshi fails to process Kotlin 1.6 metadata

Caused by: java.lang.IllegalStateException: Could not parse metadata! This should only happen if you're using Kotlin <1.1.
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.readKotlinClassMetadata(KotlinPoetMetadata.kt:89)
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.toImmutableKmClass(KotlinPoetMetadata.kt:119)
	at com.squareup.moshi.kotlin.codegen.MoshiCachedClassInspector.toImmutableKmClass(MoshiCachedClassInspector.kt:37)
	at com.squareup.moshi.kotlin.codegen.MetadataKt.targetType(metadata.kt:139)
	at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.adapterGenerator(JsonClassCodegenProcessor.kt:148)

Project with reproduction test-moshi-kotlin16.zip

realdadfish
realdadfish

As I said, this blocks the Kotlin 1.5.31 update for people like me who want to opt-in for sealed whens.

This is not true. Sealed whens are gated on the -progressive flag, which does not change the language version.

Oh, this is news, because the release notes state otherwise:

To enable this feature in Kotlin 1.5.30, use language version 1.6. (https://kotlinlang.org/docs/whatsnew1530.html#exhaustive-when-statements-for-sealed-and-boolean-subjects)

Activity icon
issue

realdadfish issue comment square/moshi

realdadfish
realdadfish

Moshi fails to process Kotlin 1.6 metadata

Caused by: java.lang.IllegalStateException: Could not parse metadata! This should only happen if you're using Kotlin <1.1.
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.readKotlinClassMetadata(KotlinPoetMetadata.kt:89)
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.toImmutableKmClass(KotlinPoetMetadata.kt:119)
	at com.squareup.moshi.kotlin.codegen.MoshiCachedClassInspector.toImmutableKmClass(MoshiCachedClassInspector.kt:37)
	at com.squareup.moshi.kotlin.codegen.MetadataKt.targetType(metadata.kt:139)
	at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.adapterGenerator(JsonClassCodegenProcessor.kt:148)

Project with reproduction test-moshi-kotlin16.zip

realdadfish
realdadfish

Is there a specific reason not to release this earlier, i.e. now? As I said, this blocks the Kotlin 1.5.31 update for people like me who want to opt-in for sealed whens.

Activity icon
issue

realdadfish issue comment square/retrofit

realdadfish
realdadfish

BOM publishing

Alternative to #3487

realdadfish
realdadfish
push

realdadfish push realdadfish/retrofit

realdadfish
realdadfish
realdadfish
realdadfish

Add dependabot for GitHub Actions

realdadfish
realdadfish

Update all the GitHub Actions

realdadfish
realdadfish

Commit a stable keystore for test APK

realdadfish
realdadfish

Merge pull request #3579 from christofferqa/update_keep_rules

Add keep rule to retain generic signature of Call

realdadfish
realdadfish

Merge pull request #3563 from mkj-gram/add-kotlin-continuation-keeprule

Add keep rule for kotlin.coroutines.Continuation

realdadfish
realdadfish

Merge pull request #3583 from square/jw/updates/2021-06-29

Build/CI updates

realdadfish
realdadfish

Add test for Content-Type in GET request

realdadfish
realdadfish

Remove RoboVM Gradle plugin and test

It is currently incompatible with running on JDK 16.

realdadfish
realdadfish

Merge pull request #3552 from square/jw/get-content-type-test/2021-04-29

Add test for Content-Type in GET request

realdadfish
realdadfish

Merge pull request #3584 from square/jw/sixteen/2021-06-29

Add Java 16 build

realdadfish
realdadfish

Add proguard config for R8 to keep type information for RxJava stuff

realdadfish
realdadfish

Merge pull request #3596 from neworld/feature/r8_rules_for_rxjava

Add proguard config for R8 to keep type information for RxJava stuff

realdadfish
realdadfish

Add a JAXB 3 converter (#3555)

Co-authored-by: Jake Wharton [email protected]

realdadfish
realdadfish

Bump protobuf to restore Android compatibility (#3597)

  • Bump protobuf to restore Android compatibility

Below API 26.

  • Update protobuf for Apple M1 support
realdadfish
realdadfish
realdadfish
realdadfish

Merge pull request #3598 from jzbrooks/keep-response-sig

Keep signature for Response

commit sha: cbfef96874bf2e7b670c077abedc39808d5abeab

push time in 1 month ago
Aug
30
1 month ago
Activity icon
issue

realdadfish issue comment square/moshi

realdadfish
realdadfish

Moshi fails to process Kotlin 1.6 metadata

Caused by: java.lang.IllegalStateException: Could not parse metadata! This should only happen if you're using Kotlin <1.1.
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.readKotlinClassMetadata(KotlinPoetMetadata.kt:89)
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.toImmutableKmClass(KotlinPoetMetadata.kt:119)
	at com.squareup.moshi.kotlin.codegen.MoshiCachedClassInspector.toImmutableKmClass(MoshiCachedClassInspector.kt:37)
	at com.squareup.moshi.kotlin.codegen.MetadataKt.targetType(metadata.kt:139)
	at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.adapterGenerator(JsonClassCodegenProcessor.kt:148)

Project with reproduction test-moshi-kotlin16.zip

realdadfish
realdadfish

Happens to me in a Gradle build as well, as soon as I set the languageVersion to "1.6" (to make use of the sealed when preview in Kotlin 1.5.30):

Caused by: java.lang.IllegalStateException: Could not parse metadata! This should only happen if you're using Kotlin <1.1.
        at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.readKotlinClassMetadata(KotlinPoetMetadata.kt:89)
        at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.toImmutableKmClass(KotlinPoetMetadata.kt:119)
        at com.squareup.moshi.kotlin.codegen.MoshiCachedClassInspector.toImmutableKmClass(MoshiCachedClassInspector.kt:37)
        at com.squareup.moshi.kotlin.codegen.MetadataKt.targetType(metadata.kt:139)
        at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.adapterGenerator(JsonClassCodegenProcessor.kt:148)
        at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.process(JsonClassCodegenProcessor.kt:114)
        at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt:90)
        at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:188)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:980)
        ... 41 more

This seems to be the upstream tracking bug: https://youtrack.jetbrains.com/issue/KT-47945 And yes, kotlinx-metadata is already silently updated to 0.3.0 for me as well and there doesn't seem to be a newer version of this library available.

+--- com.squareup.moshi:moshi-kotlin-codegen -> 1.12.0
|    +--- com.squareup.moshi:moshi:1.12.0
|    |    +--- com.squareup.okio:okio:2.10.0
|    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.4.20 -> 1.5.30 (*)
|    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.4.20 -> 1.5.30
|    |    \--- org.jetbrains.kotlin:kotlin-stdlib:1.4.31 -> 1.5.30 (*)
|    +--- org.jetbrains.kotlin:kotlin-reflect:1.4.31 -> 1.5.30
|    |    \--- org.jetbrains.kotlin:kotlin-stdlib:1.5.30 (*)
|    +--- com.squareup:kotlinpoet:1.8.0
|    |    +--- org.jetbrains.kotlin:kotlin-reflect:1.4.31 -> 1.5.30 (*)
|    |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.31 -> 1.5.30 (*)
|    +--- com.squareup:kotlinpoet-classinspector-elements:1.8.0
|    |    +--- com.squareup:kotlinpoet-metadata-specs:1.8.0
|    |    |    +--- com.squareup:kotlinpoet:1.8.0 (*)
|    |    |    +--- com.squareup:kotlinpoet-metadata:1.8.0
|    |    |    |    +--- org.jetbrains.kotlinx:kotlinx-metadata-jvm:0.2.0 -> 0.3.0 (*)
|    |    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.31 -> 1.5.30 (*)
|    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.31 -> 1.5.30 (*)
|    |    +--- com.google.guava:guava:29.0-jre (*)
|    |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.31 -> 1.5.30 (*)