[pjmlp]

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.

[dtech]

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.

* at the expense of expanded bytecode size

[pjmlp]

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.

[hunterpayne]

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.

[pron]

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!"

[clhodapp]

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.

[geokon]

Didn't Google win the lawsuit with Oracle?

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.

Ex: I just took a look at a dependency I'm using

https://github.com/locationtech/spatial4j

Can it be used on Android..? I have no idea

From what I understand it's a weird stack now where nobody is actually writing Java for Android.

I'm still waiting for the day I can write a Clojure app for my phone..

(and not a Dart chat app.. but something actually performant that uses the hardware to the full extent)

[refulgentis]

> 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.

[pjmlp]

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.

[imtringued]

What you're asking for is essentially commercial support from Oracle.

[hunterpayne]

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.

[Pet_Ant]

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.

[jolux]

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.

[gavinray]

There are Kotlin compiler flags to default to "indy" optimization, and which may be enabled by default for some time now?

Also not all Kotlin inlines are lambdas or even include method calls