https://kotlinlang.org logo
#amper
Title
# amper
r

routis

11/27/2023, 5:16 PM
A couple questions: 1. Amper's repo contains no source code (of amper itself). Is it going to be an open source tool?
a

artspb

11/27/2023, 5:17 PM
It does now.
👍 1
l

Landry Norris

11/27/2023, 5:17 PM
Looks like the prototype code was pushed yesterday
👌 1
r

routis

11/27/2023, 5:20 PM
😀 Totally missed this folder
2nd question Used the amper's new layout and the
gradle-kmp
for a lib project with a single target (jvm). In both layouts I put common code into
src
and
commonMain/kotlin
respectively. No matter the layout, my source code (in commonMain) keeps compiles despite it uses java packages. I would expect that
src
or
commonMain
would compile only common platform code, when
src@jvm
or
jvmMain
are present. Is this behavior a feature or a bug?
l

Landry Norris

11/27/2023, 5:28 PM
That's how KMP currently works regardless. Common means common to all platforms being used. I think this is due to a set of 'common to all present and future platforms' methods/classes not being defined.
r

routis

11/27/2023, 5:47 PM
I had the impression that in
commonMain
you cannot use java packages. For instance BigInteger cannot be used. In the context of Amper ( in default layout, or in
gradle-kmp
) I can use for instance
BigInteger
in
src
or in
commonMain
for a lib project that targets only
jvm
I was expecting a compilation error.
w

Waldemar Kornewald

11/27/2023, 5:54 PM
I also found that confusing. The meaning of common is purely based on the targets for that module
✔️ 1
l

Landry Norris

11/27/2023, 5:56 PM
You can use java packages if all targets support java. For example, you may have a jvm/android project, in which case, some java APIs may be useful. In a single target project, commonMain is technically the same as the platform source set. It's the same with gradle.
It's often good to define the full list of targets you plan to support up front, even if you don't plan to implement the entry point now.
w

Waldemar Kornewald

11/27/2023, 5:59 PM
Couldn't this be changed, so every source set has a project/target independent meaning? Common would always have to work on all platforms. Native would always mean all native targets supported by the compiler. And so on.
That way everything would be consistent and unsurprising
l

Landry Norris

11/27/2023, 6:02 PM
There'd need to be a defined set of methods/classes that all future compiler backends have to support in order to do that. There's a youtrack to define a 'pure kotlin', but I don't remember the number off the top of my head.
w

Waldemar Kornewald

11/27/2023, 6:05 PM
If the vision is for people to mostly just write libraries for common then we need some change to the current behavior
Not sure if "pure Kotlin" is sufficient though. Maybe if that also contains a sufficiently complete stdlib🤔
l

Landry Norris

11/27/2023, 6:06 PM
If you're writing a common library, you can add the list of platforms you support, and common will commonize them.
Found the youtrack: https://youtrack.jetbrains.com/issue/KT-52666/Kotlin-Multiplatform-libraries-without-platform-specific-code-a.k.a.-Pure-Kotlin-libraries-Universal-libraries Without this, it's not possible to guarantee that new platforms will support everything in the current 'common'
w

Waldemar Kornewald

11/27/2023, 6:08 PM
Yes I'd just like to have better defaults. In other languages it feels like you write common code by default. In Kotlin something is unnatural about that
plus1 1
2 Views