A modern programming language that makes developers happier.

kotlinlang

I wonder if Java Jigsaw modules can improve performance, by reducing the scope of the code the IDE must consider during completion

One of the big issues with Jigsaw is that Kotlin projects would be heavily coupled to the JVM, unless those Kotlin projects will only be targeting the JVM and there are no plans to target additional platforms later on.

A much better solution is to utilise KLibs (Kotlin's equivalent to Jigsaw) once the KLib format has been stabilised.

Currently KLibs are only available on Kotlin Native, however there are plans to roll out KLibs to other Kotlin development platforms (Kotlin JVM, Kotlin JS, Kotlin Android). Refer to the blog post for more details: <https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/>

Why would Jigsaw couple you tightly to the JVM? It's just one additional file, a module descriptor.

I don't see how a KLib could be used meaningfully on the JVM outside of new clever stuff like Truffle, or what advantages it'd bring.

The goal here is just better control over scope. `internal` isn't always ideal, at least, it requires the IDE to consider every class and function individually rather than rapidly eliminate based on package.

With Truffle are you referring to GraalVM?

One of the major advantages with KLib is that it supports Kotlin multi-platform development unlike Jar/Java Modules, which is restricted to the JVM via its cross-platform support as long as the JVM is targeted.

Yeah, GraalVM. JVM *is* cross platform, that was one of the original design goals, right? Write once run anywhere :slightly_smiling_face: You can run bytecode in JS using TeaVM (developed by jetbrains no less) and compile to standalone binaries with native-image. So the question is really about whether KLib is a better format than .class files or not. That's a question I'd be really interested in, as it's certainly possible to do better than jar/.class and JetBrains have a good track record. But AFAIK Klib is hardly documented at the moment.

Well, it's documented as containing LLVM bitcode, which presumably won't be the 'serialized IR' format they use going forwards.

Pity that LLVM bitcode won't be the IR format for the Kotlin compilers. It is a missed opportunity to have Kotlin Native supported by GraalVM (via Sulong - <https://github.com/oracle/graal/tree/master/sulong> ) since it would create the possibility of a communication bridge between the JVM and Kotlin Native libraries, without having to deal with the dreaded JNI system.

LLVM bitcode isn't a good portable IR, that's why.

There were attempts to use LLVM as such in the past e.g. by Apple, and also on the web, but it didn't work out, hence WebAssemblhy.

One problem is LLVM bitcode isn't portable. It encodes a lot of stuff specific to the machine it was produced on, e.g. word size, operating system, on Linux, distribution specific stuff. Another is it's really large and complex, and not really specified properly. It's a tool for the LLVM toolchain, not a distribution format. In contrast JVM bytecode (and WebAssembly) are carefully specified and relatively small/stable formats.,

Given that KLib is going to become serialised Kotlin compiler IR, it'll be interesting to see whether it ends up more like LLVM (large, complex, under specified, very language specific) or more like JVM bytecode.