4 ms·

> So, Vulkan is now compulsory There is nothing to suggest that Vulkan is now required. > Speaking of which, it is going to be the usual partial Java 8 varian

> So, Vulkan is now compulsory 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.

Twirrim 8y ago
> 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."
- kllrnohj 8y ago
  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.
  - desdiv 8y ago
    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.
    - kllrnohj 8y ago
      Nearly every Android TV is 32-bit, and many low-end Android devices ship in 32-bit configuration even if the hardware is 64-bit for RAM reasons. Both of them run arbitrary 3rd party apps. They also form basically the entirety of the GLES 2.0 portion of this pie chart: https://developer.android.com/about/dashboards/index.html#OpenGL https://developer.android.com/about/dashboards/index.html#Op...
      - pjmlp 8y ago
        Which means they won't run much new apps in 2020.
  - pjmlp 8y ago
    I wonder what those 32-bit devices would be good for. > We're also moving the ecosystem toward readiness for 64-bit devices. Later this year, Google Play will require 64-bit support in all apps -- https://android-developers.googleblog.com//2019/03/introducing-android-q-beta.html https://android-developers.googleblog.com//2019/03/introduci...
pjmlp 8y ago
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.
- kllrnohj 8y ago
  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.
  - pjmlp 8y ago
    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.
    - kllrnohj 8y ago
      > support for constant pools Are you thinking of Java 11's Dynamic Class-File Constants or Java 12's JVM Constants API? > nested class changes What nested class changes? > Of the complete Java standard library for that matter. What is missing other than the few new additions (like Flow) in recent versions? Or are you mistakenly considering javax.* part of the Java standard library? Because it's not, which Java 9 reinforced as part of Project Jigsaw.
MrZipf 8y ago
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.

Twirrim 8y ago

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

kllrnohj 8y ago
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.
- desdiv 8y ago
  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.
  - kllrnohj 8y ago
    Nearly every Android TV is 32-bit, and many low-end Android devices ship in 32-bit configuration even if the hardware is 64-bit for RAM reasons. Both of them run arbitrary 3rd party apps. They also form basically the entirety of the GLES 2.0 portion of this pie chart: https://developer.android.com/about/dashboards/index.html#OpenGL https://developer.android.com/about/dashboards/index.html#Op...
    - pjmlp 8y ago
      Which means they won't run much new apps in 2020.
- pjmlp 8y ago
  I wonder what those 32-bit devices would be good for. > We're also moving the ecosystem toward readiness for 64-bit devices. Later this year, Google Play will require 64-bit support in all apps -- https://android-developers.googleblog.com//2019/03/introducing-android-q-beta.html https://android-developers.googleblog.com//2019/03/introduci...

pjmlp 8y ago

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.

kllrnohj 8y ago
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.
- pjmlp 8y ago
  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.
  - kllrnohj 8y ago
    > support for constant pools Are you thinking of Java 11's Dynamic Class-File Constants or Java 12's JVM Constants API? > nested class changes What nested class changes? > Of the complete Java standard library for that matter. What is missing other than the few new additions (like Flow) in recent versions? Or are you mistakenly considering javax.* part of the Java standard library? Because it's not, which Java 9 reinforced as part of Project Jigsaw.

MrZipf 8y ago

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.