There is nothing to suggest that Vulkan is now required.
> Speaking of which, it is going to be the usual partial Java 8 variant, and Java 12 is going live next week.
Java's version number has been hijacked to mean OpenJDK's runtime version & handful of non-core library updates that don't exist on Android anyway.
It has vanishingly little to do with the actual language or core libraries these days.
The only thing of interest at all between Java 9, 10, and 11 are var handles (compiler-only, no runtime support needed - should work fine on Android), and the Flow class. Which is unfortunately missing, yes, but not particularly significant. Might work better as an AndroidX addition anyway.
Since Twirrim already tackled Vulkan, I will only answer on the Java part.
The only thing of interest for Java developers, is being able to use any standard Java library out of Maven central, instead of having two versions or minimal common code, and not excusing Google for having successfully created a fork in the Java eco-system, aka Android J++.
Rest assured when Valhalla and Panama finally land, it will only get worse.
The only thing that matters for library interop is the bytecode version, not the "Java" version. Binary version & source version have been different attributes in Java going all the way back to the J2ME days.
> Rest assured when Valhalla and Panama finally land, it will only get worse.
You're assuming that Android won't have support for those, but that assumption is unfounded. Android has so far gotten support for all the bytecode-level changes that have happened like invoke-dynamic.
Java 9, 10, and 11 have not changed the bytecode. Nothing about the compiled binary has changed to require support. And outside of Flow none of the core libraries have changed, either.
There's no forking or hijacking in play here. Oracle just hasn't done anything that needs support from a runtime since Java 8.
Ah my mistake then. Is there any way to actually use that instruction from Java though? Or is this just bytecode support for a potential future feature?
It gets used by the compiler, so unless ART gets to understand it, those nice Java 11 libraries at Maven central that might make use of it are a no go on Android.
And yes, it is also related to the ongoing Valhala efforts.
So where is Android support for constant pools or nested class changes?
Of the complete Java standard library for that matter.
Of course I am assuming the worse from a company that insists in getting away with Android J++, while having fanboys supporting their agenda, many of which were even on the first row against the old J++.
But I get it, the "Do no evil" company has lots of SV love.
> There is nothing to suggest that Vulkan is now required.
From the article:
"We're working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices."
Which means it's not required as long as 32-bit devices are allowed to ship as well. It will be a large percentage, like GLES 3 is, but not required, like GLES 3 isn't.
I googled around and honestly can't find a single phone introduced in 2019 that's still 32-bit.
Sure, embedded non-phone Android devices could still be built with 32-bit CPUs to cut costs, but those devices typically don't let user install 3rd party apps in the first places so they're not relevant to the discussion.
Preliminary VarHandle support in Android start in P. The API is hidden, but it had to start ahead of the Java 9 libraries because it's a lot of work.
All code needs to be capable of being interpreted as that's the fallback when compilation invariants are violated (and also when stepping through code with the debugger).
A large number of operations combined with different vartypes and backing store types (fields, static fields, arrays, Buffers, etc) makes for a lot of work, even though this is just the slow path.
There is no compiler support yet for VarHandles, or MethodHandles, on Android, but there are bugs on these.
There is nothing to suggest that Vulkan is now required.
> Speaking of which, it is going to be the usual partial Java 8 variant, and Java 12 is going live next week.
Java's version number has been hijacked to mean OpenJDK's runtime version & handful of non-core library updates that don't exist on Android anyway.
It has vanishingly little to do with the actual language or core libraries these days.
The only thing of interest at all between Java 9, 10, and 11 are var handles (compiler-only, no runtime support needed - should work fine on Android), and the Flow class. Which is unfortunately missing, yes, but not particularly significant. Might work better as an AndroidX addition anyway.