A couple questions: 1. Amper's repo contains no s...

# amper

[routis]

A couple questions:

1. Amper's repo contains no source code (of amper itself). Is it going to be an open source tool?

[artspb]

It does now.

[Landry Norris]

Looks like the prototype code was pushed yesterday

[routis]

😀 Totally missed this folder

[routis]

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?

[Landry Norris]

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.

[routis]

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.

[Waldemar Kornewald]

I also found that confusing. The meaning of common is purely based on the targets for that module

[Landry Norris]

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.

[Landry Norris]

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.

[Waldemar Kornewald]

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.

[Waldemar Kornewald]

That way everything would be consistent and unsurprising

[Landry Norris]

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.

[Waldemar Kornewald]

If the vision is for people to mostly just write libraries for common then we need some change to the current behavior

[Waldemar Kornewald]

Not sure if "pure Kotlin" is sufficient though. Maybe if that also contains a sufficiently complete stdlib🤔

[Landry Norris]

If you're writing a common library, you can add the list of platforms you support, and common will commonize them.

[Landry Norris]

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'

[Waldemar Kornewald]

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