-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Kotlin Multiplatform #1123
Comments
Will do, alongside with coming v1.1.1 release. |
Hi
Not sure what is meant exactly here. |
I see no problems having both Java and Kotlin (once Kotlin version could be transpiled from Java one). |
@slandelle correct, not a replacement, of course. |
Could it be supported on JAVA 8+ ? |
I am not sure what you are asking. Kotlin produces by default Java 8 bytecode and a Kotlin port should just work. https://kotlinlang.org/docs/faq.html#which-versions-of-jvm-does-kotlin-target |
As I have a JAVA 8 project, I was wondering if this could work for my project. I guess the bytecode interoperability should do the job. Thanks for your answer! 🙂 |
Added kotlin implementation of decoder. Looking at requirements for publishing. |
Great news! There is a official tutorial: Look at my project for a sample config: |
@eustas The Java dependencies prevent it from being multiplatform. brotli/java/org/brotli/dec/kt/BrotliInputStream.kt Lines 9 to 10 in ccec962
If those two classes represent everything that is used from Java API, you could replace it using https://github.com/Kotlin/kotlinx-io Kotlin Multiplatform support is way more useful than just Kotlin for JVM. On JVM we can already use the Java version, but we need a pure Kotlin implementation for Multiplatform support. So no usage of JVM api. |
Hello, any updates here ? |
I want to request official Kotlin Multiplatform support.
To achieve this, the Java implementation could be transformed into Kotlin and subsequently published as outlined in the guidelines provided at https://kotlinlang.org/docs/multiplatform-publish-lib.html#host-requirements. This approach ensures continued usability for pure Java projects.
Additionally, it's worth noting that the artifact on Maven Central appears to be outdated. Incorporating the process of pushing new artifacts to Maven Central into the build workflow would be a valuable improvement. This issue can also be addressed in this endeavor.
The text was updated successfully, but these errors were encountered: