Java 9 Tech Preview Planned For Fedora 27

[bug77]

write shit once, be shit forever.

Thank you for your insights.

[eigenlambda]

any language for Android to move to must:
(1) have programs distributed in a form that can be quickly loaded on any processor, because Androids have all kinds of processors
(2) be widely used
(3) be reasonably secure

Since Rust is obviously all three, the only reason Google isn't using it is that they're bad people who refuse to pay women. Other than Rust, there's nothing with a compelling advantage over Java.

More seriously, I wish Android's GUI parts were written in Rust so it would be responsive always instead of just most of the time if I'm using a sufficiently fast quad-core.

[eigenlambda]

svn is fine. keep your local workspace in git and use git-svn or whatever it's called now to push, this covers most of what git is used for

[DanLamb]

Plus, there's really nothing in Java 9 that's useful to Android. Most of Java 9 is about JVM improvements and Android does not use the JVM. The module system might be a useful under the hood improvement, but at this point no one really knows.

With Android Java, you're right. JDK 9 changes are basically VM and tooling level changes that doesn't impact the Android Runtime.

Android games and some written in Java usually don't use the Android Java Runtime, they use RoboVM, which is an AOT compiler than turns Java apps into Android binaries.

Last year, Xamarin bought RoboVM, then Microsoft bought Xamarin and promptly shut down RoboVM.

JDK9 has an out of the box AOT compiler and will hopefully be much better than RoboVM ever was. In that case, such non-Android Java development will grow.

If anything, I'd like to see Android ditch Java and replace it with Go That's not going to happen either.

With the bitter lawsuits, I expected Google to replace Java with either Go or a new Google language. I'm surprised they haven't.

Very few Android apps/games actually use Java. They all use some intermediate toolkit.

[DanLamb]

More seriously, I wish Android's GUI parts were written in Rust so it would be responsive always instead of just most of the time if I'm using a sufficiently fast quad-core.

This is complete programmer fanboy BS.

Both Android and Apple have hired the best graphics+GPU experts doing extreme optimization of their graphics pipelines. Not forum programmer fanboys, guys who design GPUs and video hardware. They obsess over 60FPS lock and hyper low latency. Apple iOS and Android are in an arms race to get better graphics to customers. Android doesn't use Java for the core graphics pipeline, and those teams will do whatever they can to get slight benchmark improvements. Sure, on forums like this, someone seems an end user app stutter, and sure, "JAvahhh sux", but that's not a rational or reasonable comment. Most Android apps aren't written with Java, the core graphics pipeline doesn't use Java, and if Java language or runtime was a major bottleneck, the Android team would make workarounds.

For end user apps, you can use stuff like this to make sure you have solid 60FPS lock:

https://developer.android.com/training/testing/performance.html

Many Android app authors don't care that much.

[cjcox]

Perhaps this will be the release where they admit, "Ok, maybe you really can't write once and run everywhere."

[meekteef]

This is complete programmer fanboy BS.

Both Android and Apple have hired the best graphics+GPU experts doing extreme optimization of their graphics pipelines. Not forum programmer fanboys, guys who design GPUs and video hardware. They obsess over 60FPS lock and hyper low latency. Apple iOS and Android are in an arms race to get better graphics to customers. Android doesn't use Java for the core graphics pipeline, and those teams will do whatever they can to get slight benchmark improvements. Sure, on forums like this, someone seems an end user app stutter, and sure, "JAvahhh sux", but that's not a rational or reasonable comment. Most Android apps aren't written with Java, the core graphics pipeline doesn't use Java, and if Java language or runtime was a major bottleneck, the Android team would make workarounds.

For end user apps, you can use stuff like this to make sure you have solid 60FPS lock:
https://developer.android.com/traini...rformance.html

Many Android app authors don't care that much.

Amen!

When will these amateur hour clowns realize that changing an application's programming language doesn't automatically make things faster?

[artyom.h31]

OpenJDK 9 will finally receive a proper ARM support. I feel very excited about this feature, as it will be possible to run Subsonic on my SBC without much tinkering.

[uid313]

Java 9 only introduces a programmatic HTTP/2 client (i.e. to be used by Java apps that connect to a HTTP/2 enabled server). I can't find documentation right now, but I'd be surprised if WebView doesn't already know HTTP/2. After all HTTP/2 is Google's own SPDY standardized.

Yes, I'd be surprised if WebView doesn't already do HTTP/2 too. I assume it does.
However, this is not about WebView, this is about performing JSON requests to web APIs.
WebView is if your application has a web user interface, but often you have a native Android interface with native Android widgets and the server interact with a remote server using JSON.

[andre30correia]

it's in ubuntu since 2016