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

Android downward compatibility with strikt 0.27.0 #229

Closed
nenick opened this issue Sep 8, 2020 · 8 comments
Closed

Android downward compatibility with strikt 0.27.0 #229

nenick opened this issue Sep 8, 2020 · 8 comments

Comments

@nenick
Copy link

nenick commented Sep 8, 2020

Would be great to use this library in Android development but some latest changes aren't compatible with lower Android versions than 24.

Private interface methods are only supported starting with Android N (--min-api 24): 
Lstrikt/api/Assertion$Builder;describe(Lkotlin/jvm/functions/Function1;)Ljava/lang/String;

Any ideas to workaround this issue?

@robfletcher
Copy link
Owner

robfletcher commented Sep 8, 2020

Sounds like it would be worth adding an Android build to the CI matrix. I don't really know the first thing about Android development but it might at least be able to preempt issues like this.

@robfletcher
Copy link
Owner

robfletcher commented Sep 13, 2020

I've (hopefully) fixed this by making those private interface methods package-level functions instead. I'd love to know how I could replicate this in GitHub Actions so I can avoid regressions.

@nenick
Copy link
Author

nenick commented Sep 13, 2020

This issues gets reported at "test" compile time. It should be enough to setup a basic android project with strikt as androidTestImplementation dependency and call assembleAndroidTest (does only build, not run the tests). I don't think that making them "privat" will help, but I didn't have tested it yet.

Recently I found that forcing java 8 support does help. Not the best solution but could be an acceptable one.

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

@robfletcher
Copy link
Owner

robfletcher commented Sep 13, 2020

Well, the commit I made should fix the issue but I'll look into whether I can add an Android sample project or something so that I can stop similar things in future.

Is that because Android defaults to JDK 1.6?

@nenick
Copy link
Author

nenick commented Sep 13, 2020

Yes, Android still depends on JDK 1.6 until Android 24, then JDK 1.8. The sourceCompatibility enables some JDK 1.8 features (including Private interface) but still not all.

Would be great if sourceCompatibility = JavaVersion.VERSION_1_8 can be avoided because it's add an extra compile step which does consume extra time.

Next weekend I can also start to contribute some stuff, like a simple android test project. Until there I'm on vacation ;)

@robfletcher
Copy link
Owner

robfletcher commented Sep 13, 2020

Hmm. Trying to compile Strikt itself with 1.6 compatibility opens up a bunch of errors with the JUnit dependency. Might be resolvable, but given how long 1.6 has been EOLed for now I'm not sure if the effort makes sense.

Any help you could given on Android compatibility would be great. Like I say, it's not my area of expertise. Strikt grew out of my use of Kotlin for cloud microservices, so anything I've built has been largely focused on that use case.

@nenick
Copy link
Author

nenick commented Sep 13, 2020

1.6 compatibility opens up a bunch of errors with the JUnit dependency

For Android we have two test targets. First one are plain JUnit tests on your pc (source compatibility doesn't matter here). The second one are instrumented tests on a device. Google does provide a custom JUnit implementation which does support JDK 1.6 but this is not a usable dependency for plain JUnit tests.

I agree that extra effort for JDK 1.6 makes not much sense. A simple android project which proofs the basic compatibility should be enough here.

When I understood you correctly then you would also like to get some contributions regarding github actions for Android? I didn't have used github actions yet but I will check what must have to be done for it.

@robfletcher
Copy link
Owner

robfletcher commented Sep 13, 2020

I think if there's a sample project that could be run alongside the build, that would be fine for GH Actions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants