Sebastian Sellmair [JB]
08/24/2022, 11:14 AMhfhbd
08/24/2022, 11:15 AMSebastian Sellmair [JB]
08/24/2022, 11:25 AMGrégory Lureau
08/24/2022, 12:05 PMval androidMain by getting { dependsOn(jvmMain) }
due to stuff like Date being not compatible. This kind of differences means that you eventually ends up filling jvmMain/androidMain (or else you use a library that does it for you, so same). I'd be very happy to share my compose code (I understood it's not feasible yet).Javier
08/24/2022, 12:05 PMjvmAndAndroidMain
) from compose-jb repo.
TBH that is a hack to a missing feature (well the feature exists but it doesn't work with this combination) and it is used in a lot of projects, including jetbrains oneshfhbd
08/24/2022, 12:05 PMGrégory Lureau
08/24/2022, 12:07 PMJavier
08/24/2022, 12:07 PMGrégory Lureau
08/24/2022, 12:12 PMJavier
08/24/2022, 12:13 PMGrégory Lureau
08/24/2022, 12:57 PMJavier
08/24/2022, 12:59 PMeygraber
08/24/2022, 4:55 PMandroidMain
and jvmMain
source sets with the source code in both being exactly the same. I can't use commonMain
because this module has other targets and I don't want Compose code in them.Michael Paus
08/24/2022, 6:19 PMJeff Lockhart
08/24/2022, 9:42 PMGrégory Lureau
08/25/2022, 7:12 AMDate
in the database for example, I've got runtime exceptions doing that, because JVM methods are not all available on Android.)Michael Paus
08/25/2022, 9:01 AMcommons-csv
commons-io
commons-lang3
commons-math3
earth-gravitational-model
GeographicLib-Java
indriya
jpx
jts-core
jts-io-common
org.eclipse.paho.client.mqttv3
si-quantity
si-units
unit-api
uom-lib-common
Modern Android has become very compatible with the JVM and I have seldom seen any problems. I even use Java 11 for all my libs without problem. Of course you have to prepare for it and do some testing. I only had one major problem with sqlite-jdbc which doesn’t work on android but that could be easily replaced by sqldroid, so that the rest of the code, which uses JDBC, could stay untouched. Even the Eclipse Paho MQTT-client worked without problems out of the box.
So you see that I have a large model which can be fully shared between JVM and Android and I certainly do not want to duplicate that in any way nor tear it apart for no good reason.Grégory Lureau
08/25/2022, 9:16 AMMichael Paus
08/25/2022, 9:22 AMDate
class you mean and which database. If you mean java.util.Date
then this should not be used anymore anyway. The java.time API is much better but of course I don’t know why you are using java.util.Date
. (https://developer.android.com/reference/java/time/package-summary)
The JVM interoperability also depends on your build configuration. I am using:
val JVM = JavaVersion.VERSION_11
android {
compileSdk = 32
sourceSets["main"].manifest.srcFile("src/androidMain/AndroidManifest.xml")
defaultConfig {
minSdk = 26
targetSdk = 32
}
compileOptions {
sourceCompatibility = JVM
targetCompatibility = JVM
}
namespace = ...
tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
kotlinOptions {
jvmTarget = JVM.toString()
}
}
}
Jeff Lockhart
08/25/2022, 2:37 PMkotlinx.datetime.Instant
instead of java.util.Date
, which the underlying Android and Java SDKs both use. So users won't be manipulating Date
objects with Java or Android's supported subset of APIs. This is necessary for a common date API to replace ObjC's NSDate
. actual
platform implementations each convert `Instant`s to and from their native type when interacting with the underlying database APIs.srcDir
for both android* and jvm*, works best. jvmCommon* code sees the Java platform APIs and jvm dependencies in the IDE.
The one annoyance is that common* code doesn't detect the jvm `actual`s for `expect`s. So the IDE shows
Expected class '<ClassName>' has no actual declaration in module <module-name>.main for JVMthroughout the common code. This is not an issue with the first mechanism, which would be the expected way to implement a shared source set. But not seeing platform and dependency APIs is worse than having to
@Suppress("NO_ACTUAL_FOR_EXPECT")
for every expect
(which exist in nearly every common file of my library 😣) and deal with missed actuals at compile time.
Both mechanisms technically work, all tests passing on both android and jvm. It's just IDE support that's lacking. This is a use case that is not solvable using separate modules. The article mentions this library as another example.