Skip to content
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

recordPaparazzi on Java 17 - UninitializedPropertyAccessException lateinit property sessionParamsBuilder #1031

Closed
mshearer123 opened this issue Aug 1, 2023 · 12 comments · May be fixed by #1162
Assignees
Labels
bug Something isn't working
Milestone

Comments

@mshearer123
Copy link

mshearer123 commented Aug 1, 2023

Description
Error when running paparazzi record since updating to gradle 8 / Java 17

 kotlin.UninitializedPropertyAccessException: lateinit property sessionParamsBuilder has not been initialized
        at app.cash.paparazzi.Paparazzi$Companion.getSessionParamsBuilder$paparazzi(Paparazzi.kt:626)
        at app.cash.paparazzi.Paparazzi.prepare(Paparazzi.kt:162)
        at app.cash.paparazzi.Paparazzi$apply$statement$1.evaluate(Paparazzi.kt:124)
        at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)

have added toolchains workaround

tasks.withType(Test).configureEach {
    javaLauncher = javaToolchains.launcherFor {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

Steps to Reproduce
Unable to reproduce in sample project, but will keep trying over the next few nights.

Expected behavior
Expect to be able to run record tasks as before.

Additional information:

  • Paparazzi Version: 1.3.1 / 1.3.2-snapshot
  • OS: macOS 13.5 (aarch64)
  • Compile SDK:
  • Gradle Version: 33
  • Android Gradle Plugin Version: 8.0.2

Note: Problem doesn't appear on our CI builds, on Linux

@mshearer123 mshearer123 added the bug Something isn't working label Aug 1, 2023
@mshearer123 mshearer123 changed the title recordPaparazzi - UninitializedPropertyAccessException lateinit property sessionParamsBuilder recordPaparazzi on Java 17 - UninitializedPropertyAccessException lateinit property sessionParamsBuilder Aug 2, 2023
@oleksandrbalan-etn
Copy link

oleksandrbalan-etn commented Aug 22, 2023

We have are integrated a paparazzi to our project and it works well for majority, but several of my colleagues have the same issue kotlin.UninitializedPropertyAccessException: lateinit property sessionParamsBuilder has not been initialized.

@mshearer123 Did you manage to solve it? Maybe some workaround?

Additional information:

  • Paparazzi Version: 1.3.1 / 1.3.2-snapshot
  • Compile SDK: 33
  • Gradle Version: 8.1.1
  • Android Gradle Plugin Version: 8.0.2

@mshearer123
Copy link
Author

@oleksandrbalan-etn I'm afraid not, we're still stuck. Haven't been able to reproduce in a sample project.

@rahnamaMo
Copy link

rahnamaMo commented Aug 23, 2023

We have a similar situation. I was digging a little bit into it the other day and I found something pretty weird; we all have apple silicon macs, and while checking all the logs I realised the library is trying to load layoutlib in a path that is for x86 intel macs. I debugged, and found out that it indeed considers my system as an intel macbook. I have no idea what's happening to be honest since the logic there seems to be pretty straightforward, but may be worth looking into.

private fun getNativeLibDir(): String {
    val osName = System.getProperty("os.name").toLowerCase(Locale.US)
    val osLabel = when {
      osName.startsWith("windows") -> "win"
      osName.startsWith("mac") -> {
        val osArch = System.getProperty("os.arch").lowercase(Locale.US)
        if (osArch.startsWith("x86")) "mac" else "mac-arm"
      }
      else -> "linux"
    }
    return "$osLabel/lib64"
  }

It's looking for the library in this path:

Can't load library: .../.gradle/caches/transforms-3/872ffc809c62f56d59f27c14934c6ed4/transformed/layoutlib-native-macarm-2022.1.1-beta4-f5f9f71/data/mac/lib64/libandroid_runtime.dylib

while I have it in:

 .../.gradle/caches/transforms-3/872ffc809c62f56d59f27c14934c6ed4/transformed/layoutlib-native-macarm-2022.1.1-beta4-f5f9f71/data/mac-arm/lib64/libandroid_runtime.dylib

It's not happening for everyone, but all of my teammates in our vertical are facing the same error.

@rahnamaMo
Copy link

rahnamaMo commented Aug 24, 2023

Okay, so I fixed this issue for our case, here is what I found and how I fixed it at last:

TLDR; Your Android Studio is probably running the tests on JRE 11. Make sure your JDK 17 is aarch64 native and reinstall Android Studio completely.
UPDATE Simply deleting all your x86_64 JDKs will also help, in my case I had to reinstall Android Studio as well.

TL; As you probably know System.getProperty("os.arch") returns the configuration of JRE, not your actual system. I added System.getProperty("os.arch") into one of my simple non-paparazzi unit tests and the returning value was indeed x86_64 instead of aarch64. So at this point I was sure there's nothing wrong with paparazzi specifically.

Next, I made sure I have the right version of java with the right architecture, to become 100% visually sure, I downloaded a Java 17 JDK from here for aarch64 and installed it. updated my JAVA_HOME and everything, and made sure my project in Android Studio is also using the correct JDK. Re-ran the test and still I was getting x86_64 instead of aarch64. It's worth mentioning that there was no difference between running the tests via terminal or via AS GUI. I even went one step further and deleted all other installed JDKs I had, still no luck.

But this was when I realised Android Studio is running my tests [miraculously] on JRE 11. Since all previous "invalidate cache and restart" attempts did not have a positive result, this time I just uninstalled and reinstalled Android Studio and finally after that it was working as it should have.

It is a rare corner case indeed, but to determine the actual os and architecture, one shouldn't rely on Java, it's better to do it natively. My only suggestion for the Paparazzi team is that either provide a way for us to configure the system ourselves, or to move that piece of logic to native instead of Java.

@mshearer123
Copy link
Author

mshearer123 commented Aug 24, 2023

nice work @rahnamaMo

i've tried following what you have said, same result.

if you don't mind could you let me know what version of paparazzi, compile sdk, gradle etc you are using?

@rahnamaMo
Copy link

@mshearer123 sure thing:

  • Compile SDK Version: 33
  • Build Tools Version: 31.0.0
  • Gradle Version: 8.1.1
  • Android Gradle Plugin Version: 8.0.1
  • Paparazzi Version: checked on both 1.2.0 and 1.3.1
  • Kotlin: 1.8.10
  • Groovy: 3.0.15
  • Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
  • JVM: 17.0.8 (Eclipse Adoptium 17.0.8+7)
  • OS: Mac OS X 13.5 aarch64
  • Android Studio Giraffe | 2022.3.1 Patch 1

@oleksandrbalan-etn
Copy link

I can confirm what @rahnamaMo found about x86 architecture, that was really helpful, thx 🤗

Deleting all x86 JDKs and leaving only arm64 ones did the trick in our case.

@rahnamaMo
Copy link

@oleksandrbalan-etn that's amazing news 🥳 So glad I could help.

@mshearer123
Copy link
Author

Same, once all other JDKS were removed.

thanks @rahnamaMo @oleksandrbalan-etn

@iamutkarshtiwari
Copy link

I am facing the same issue.
I am running paparazzi in a Github action with the following config:

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'
          architecture: ''
          overwrite-settings: false
      - name: Check out code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Run screenshot tests
        id: run-screenshot-tests
        run: ./gradlew verifyPaparazziDebug

But it fails with the same error

evant added a commit to evant/paparazzi that referenced this issue Nov 21, 2023
use /usr/bin/arch to detect what architecture we are actually running on
instead of what arch the jre was built for. This fixes the case of using
an intel version of the jvm on arm.

Fixes cashapp#1031
evant added a commit to evant/paparazzi that referenced this issue Nov 21, 2023
use /usr/bin/arch to detect what architecture we are actually running on
instead of what arch the jre was built for. This fixes the case of using
an intel version of the jvm on arm.

Fixes cashapp#1031
@jrodbx jrodbx added this to the 1.3.3 milestone Jan 22, 2024
@jrodbx jrodbx self-assigned this Feb 22, 2024
@jrodbx jrodbx modified the milestones: 1.3.3, 1.3.4 Feb 29, 2024
@jrodbx jrodbx modified the milestones: 1.3.4, 1.4 Apr 4, 2024
@shoaibmushtaq25
Copy link

Since, I am using MAC with Apple chip.
I had the same issue. Uninstalling all JDKs with x86_64 and keeping arm64 JDKs works for me.
Thanks for the insights @rahnamaMo 👍

@jrodbx jrodbx modified the milestones: 1.4, 1.3.5 May 23, 2024
@jrodbx
Copy link
Collaborator

jrodbx commented May 29, 2024

Closing as wontfix, since this is a user environment issue, and there's a suitable workaround (thanks @rahnamaMo!)

@jrodbx jrodbx closed this as completed May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants