Flutter for Linux

> important the point still is that Android should totally switch to openjdk, end of story

Not "end of story" at all - why should Android switch? You mentioned ZGC & Shenandoah, but why do you think that would be a benefit? Have you actually tried benchmarking your app in ART vs. OpenJDK? Do you have any clue at all if ZGC would even be an improvement in your workloads, or the workloads of a typical Android app for that matter? There's a lot of really cool work going on in that space, but for example ZGC's NUMA awareness won't do diddly shit for your Android app, so things like that are pretty moot.

Meanwhile ART has optimizations that OpenJDK doesn't, like importing profiles to AOT compile parts of an app that's never been run locally before: https://android-developers.googleblog.com/2019/04/improving-...

Similarly OpenJDK's startup time & memory usage is historically quite bad, because it's just not a primary use case for them in the same way it is for ART. OpenJDK finally got some improvements in those areas very very recently ( https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht... ), but it's still not good and far from being obviously superior on all metrics to ART. And ART isn't standing still, either, with new improvements like even faster incredibly fast FFI support: https://android-review.googlesource.com/c/platform/art/+/132... Which is important for achieving things like 120hz 2D UI rendering while also running on incredibly slow in-order non-speculating power saving little cores. Which is a use case & scenario OpenJDK has never been asked to deal with nor optimized to handle.

OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. After all, nobody ever accused a Java desktop application of being fast & responsive.

> OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here.

Indeed, that is why since around 2000 there are multiple JVM implementations, including plenty of them with AOT and JIT cache capabilities.

The now gone WebSphere Realtime JVM already supported importing profiles for their AOT/JIT compilers.

And in what concerns phone devices, Microsoft did it first with their Cloud compiler for MSIL on Windows Store, first with MDIL/Bartok taken from Singularity for Windows Phone 8.x, followed up by the .NET Native toolchain on Windows 10.

Google's marketing is good, but not very influential for those that actually know the Java eco-system and the offerings available across all major vendors.

Also here is the confirmation that they will carry on cherry picking OpenJDK features instead of full compatibility.

" u/dessert_maker: We pick additional OpenJDK APIs for each Android release based on inputs from our developers. Android 11 will support additional APIs from OpenJDK 9. Everyone that is developing in Java and Kotlin should be able to take advantage of these newer additions.

In addition, we have added library desugaring to the build toolchain in Android Studio to make a wide variety of APIs across OpenJDK 8, 9, 10, and 11 available regardless of what version of Android your app runs on.

We expect to add support to the platform for more modern APIs (11,13,14) based on the level of adoption we see from our broader developer community in future versions. As mentioned in last year's AMA, making the overall runtime updatable is something we are thinking about as part of Project Mainline."

-- https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_...

So thank you Google for Android Java and like J++, forcing Java library authors to code specifically for Android, or just ignore it and focus on the myriad of JVM compatible implementations instead.

> I also hope against hope that qt is officially supported as a backend so KDE is not left out.

Unlikely (GNOME market share) and I can't see why it'd be that important. Platform protocols can be implemented around GTK and as far as I understand GTK is just a vehicle for getting X11/Wayland compatibility, the rendering itself will always be done by Flutter's engine anyway.

Non-animated changed are offensive to me. Humans are built to track moving things, not a thing instantly disappearing at one point and another, similar looking thing instantly appearing at another place, with no context telling you whether it's actually the same object. This gets worse the larger the state change is.

Similarly information overload is an issue, but of course too little information is as well. That's on the designers, though, you can certainly build information dense apps with Flutter if you want to.

From what I can tell there seems to be a platform multiplier for animations to enable slow motion mode (an important tool for developing good transitions), which I suppose you could just set to 0. And if it doesn't it's just on the developer again.

Basically: I won't deny that it can certainly influence decisions (actually I think it's an important thing to consider), but ultimately it's not really the plattform's fault if a developer decides to make an app you don't like.

I think the goal of running native speed compiled-ish code on the browser in a sandboxed way would be great if it worked. CSS and HTML for "apps" has always seemed like a hack to me. The problem is every single attempt to do this in the past has resulted in a bloated mess. Maybe this time will be different...