Kotlin heavily uses the inline keyword basically everywhere, to get rid of lamdba overhead for functions like map. Basically every stdlib and 3rd part library function that takes a lamdba is inlined.
In general it's a performance benefit and I never heard of performance problems like this. I wonder if combined with Scala's infamous macro system and libraries like quicklens it can generate huge expressions which create this problem.
This is one example why being a guest language isn't optimal.
They should have made use of JVM bytecodes that allow to optimize lambdas away and make JIT aware of them, via invokedynamic and MethodHandle optimizations.
Naturally they cannot rely on them being there, because Kotlin also needs to target ART, JS runtimes, WebAssembly and its own native version.
Kotlin existed before Java 7 and kept support JVM 1.6 for a long time (mainly because of Android)
Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement.
Java 7 to Java 25 is a world apart, and then on which JVM?
Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness.
If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't.
If they were, both languages would be supported and compete on merit, instead of sniffling one to push their own horse.
Even on their Podcast they reveal complete lack of knowledge where Java stands.
Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance for being too arrogant to listen to the market.
PS Yes, I know, there is some weird way to disable it. Somehow that way changes every version and is about as non-intuitive as possible. And trying to actually support the encapsulation is by a wide margin more work than it is worth.
First, the number of projects still on 8 is low, and almost all of them are legacy projects with little to no evolution.
Second, modules' encapsulation is not what caused the migration difficulties from 8 to 9+, evidenced by the fact that it wasn't even turned on until JDK 16: https://openjdk.org/jeps/396. From JDK 9 through 15, all access remained the same as it was in 8. The reason a lot of stuff broke was the JDK 9 was the largest release ever, and it began changing internals after some years of stagnation. Many JDK 8 libraries had used those internals and had become dependent on them not changing - though there was no promise of backward compatibility - because there was no encapsulation.
Finally, the market clearly wants things like projects Loom and Panama and Valhalla, things that wouldn't have been possible without encapsulation (at least not without breaking programs that depend on internals over and over). It's like people complaining about the noise and dust that installing cable ducts causes and say, "nobody asked for this, we just asked for fast internet!"
I'm pretty sure that the majority of shops that aren't worrying about Android have moved on from Java 8. The JVM team only keep Java 8 working for customers paying them lots of money for extended support contracts. And that's only because they have this long-term extended support system for all LTS JVM releases (they are also still supporting 11 in a similar manner).
On the other hand, Android doesn't even support Java 8. It supports the long-dead Java 7 plus a subset of Java 8 features. Android essentially froze their core application runtime in amber over ten years ago and have just been adding layer upon layer of compiler-level sugar ever since. The effect is an increasing loss of the benefit of being on the Java platform, in terms of code sharing.
I never understood why they do not track the OpenJDK versions. I don't work on Android apps.. but it seems mildly insane to basically have a weird almost-Java where you aren't even sure if you can use a given Java lib.
> I never understood why they do not track the OpenJDK versions. I don't work on Android apps.. but it seems mildly insane to basically have a weird almost-Java where you aren't even sure if you can use a given Java lib.
NIH syndrome
> (and not a Dart chat app.. but something actually performant that uses the hardware to the full extent)
I used to work on Android, quit two years ago and have used Flutter since, it's a breath of fresh air. It does use the hardware to the full extent, imo it's significantly more performant: it does an end-around all the ossified Android nonsense.
Hmm, so if you wanted to make an AR app, or some audio processing app, would you do that in Flutter? All the projects I have in mind involve using the camera/microphone/gps etc. Looking at Dart sample projects it just seemed to be quite different from what they're aiming at
My caffeinated instinct is to say basically "yes I'd do anything in Flutter", I honestly would rather stop coding than go back to anything I've done before (ObjC/Swift/Java/Kotlin with side journeys in C++). It boggles my mind how much of a different job dev is with true hot reload.
More carefully, and dealing with what you're indicating more directly:
There's stuff that we just need every millisecond of performance from.
Generally, Dart's great, I don't notice any difference between iOS / Android standard UI platforms.
But...for example, Flutter's image decoding is actually using "native" code behind the scenes, i.e. calling into C or OS-level APIs or browser APIs as needed on each platform. And there's a Flutter package called "image" that's Dart-native but I abhor because I know it's going to be higher latency than going thru lower-level code. (now I'm wondering how Java does this...I wonder if its JNI...)
Let's do a scenario: I've been contracted to build a bus route app for the local gov't. They want an AR feature. What happens if I choose to build on Flutter, build out the basic features, then get to the AR, and I'm getting 5 fps?"
This might feel convoluted at first, it did to me, but really, all that's going on is: when things are slow, we write a Dart interface, then for each platform where we want to use native code, provide impls of that interface in native.
Yeah, I'm currently developing a Flutter app and also using flutter_rust_bridge to separate the business logic and I can hardly believe how enjoyable it is.
Other than the initial project setup which is a me and Nix flakes problem it all comes together pretty smoothly.
I have not done a Java 8 project in years, other than Android because the reasons we all know.
Maybe Google could finally support latest Java versions on Android, instead of begrudgingly update when Kotlin lags behind Maven Central most used versions.
Which by the way is a Java 17 subset, not Java 8, when supporting Android versions below Android 12 isn't required.
Nope, what I am asking for is disabling an on by default feature that maybe 1% of the market wants and/or needs and creates significant pain for the other 99%. By the time strong encapsulation meets an attacker, the battle is already lost most of the time.
That feature is necessary to enable future enhancements. It’s an important stepping stone. Just update your code. I’m doing it on 20 year old legacy billion dollar code base. It can be done.
It's not just for security, it's also for maintainability. Frankly being able to reflect across package boundaries has always seemed like a misfeature for maintainability to me. The code you have that is broken by Java 9 was already badly behaved, the JVM was just lenient about it.
In general it's a performance benefit and I never heard of performance problems like this. I wonder if combined with Scala's infamous macro system and libraries like quicklens it can generate huge expressions which create this problem.