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 14 hours ago | parent | next [-]

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 a day ago | parent | prev | next [-]

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 20 hours ago | parent [-]

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 19 hours ago | parent [-]

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

▲

geokon 19 hours ago | parent | next [-]

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

	▲	refulgentis 7 hours ago \| parent [-]
		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?" Solution to that is "plugins" - https://docs.flutter.dev/packages-and-plugins/developing-pac... - the intro to the doc is way out of date, like years. TL;DR is you can drop in C / Swift / Java / whatever easily as needed. You can get a sense of what that looks like from my package for doing ML inference here: https://github.com/Telosnex/fonnx, specifically https://github.com/Telosnex/fonnx/tree/main/lib/models/minis...: X_native.dart shows us calling into shared C code on every non-mobile platform. On mobile, I have to take a dep on specific packaged & code signed libraries provided by Microsoft for ONNX. Then, I (AI, at this point) writes Swift and Kotlin to call into that library. (Swift: https://github.com/Telosnex/fonnx/blob/main/ios/Classes/OrtM..., Kotlin: https://github.com/Telosnex/fonnx/blob/main/android/src/main...) 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.

▲

aquariusDue 15 hours ago | parent | prev [-]

RE: Flutter

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.

▲

pjmlp a day ago | parent | prev | next [-]

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 a day ago | parent | prev [-]

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

▲

hunterpayne a day ago | parent [-]

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 a day ago \| parent \| next [-]
		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 19 hours ago \| parent \| prev [-]
		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.