
Future of Java 8 Language Feature Support on Android - BrianHV
https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html
======
dkarl
The possibility of running Scala >=2.12 (or any other language that is
committed to Java 8[1]) on Android seems even more remote now. Jack+Jill at
least promised a way of running Java 8 bytecode on Android[2]. What now? Is
Java source code going to be the only common currency between the Java 8 and
Android ecosystems?

[1] [https://www.scala-
lang.org/download/#Software_Requirements](https://www.scala-
lang.org/download/#Software_Requirements)

[2] [http://stackoverflow.com/questions/35958814/how-jack-java-
an...](http://stackoverflow.com/questions/35958814/how-jack-java-android-
compiler-kit-will-affect-scala-developers)

~~~
makeramen
Kotlin is committed to Android support though, and the community is coming to
rally behind it much more than Scala.

~~~
bad_user
Kotlin is just a Java++, akin to what CoffeeScript is to JS, a Java with a
different syntax.

Scala is not just a Java with a different syntax. Because of how traits work
and because of how they were encoded in Java's class format, in older Scala
versions even adding a method with a default implementation breaks binary
compatibility, which is why the history of Scala has been so fraught with
compatibility breakage.

Scala 2.12 takes advantage of Java 8's new default methods in interfaces,
among others, for encoding Scala's features. We finally have a Scala version
that isn't so fragile. And because of the limited resources of the core team,
they can't maintain different backends.

Java 8 was released in 2014. I cheered for Google when they won Oracle's
lawsuit, but when you're forking the ecosystem, you have a responsibility to
keep on your promise of keeping up to date and compatible with the upstream.
They just pulled a Microsoft and are getting away with it.

Fuck Google for fracturing the Java ecosystem. There, I said it.

~~~
cel1ne
Kotlin is not CoffeeScript for Java.

Kotlin is Java done much better. Null as syntax, extensions with receivers,
reified typing, type-safe builders, first-class lambdas, sealed classes, co-
routines and so much more...

Kotlin is my language of choice for just about everything at the moment.

I have done 15+ years of programming in Java (Desktop, Server, Android),
JavaScript (ES5, ES6+), Kotlin and a little programming in Coffee-script. Your
comparison is just wrong.

It's 100% compatible to Java so of course it's not a completely different
language. Haskell is a different language. I like Haskell, but I'm glad that I
don't have to convert all my old java code to it.

I can open old java-projects and use Kotlin on a file-by-file basis without
any problems.

~~~
pkolaczk
Kotlin doesn't really have true reified generics (any more than e.g. Scala
has), Java 8 has first class lambdas, extension methods and @Nullable now.
Kotlin is just Java 8 with cleaner syntax.

~~~
ptx
I'm no expert on Java 8, but it looks like the new feature they call
"extension methods" is just the ability to define methods in interfaces and
inherit them, essentially like a concrete method in an abstract base class,
isn't it?

The "extension methods" in Kotlin (and C#) is a completely different feature:
syntactic sugar for static utility methods, which allow you to add new methods
to any class without needing to modify the original class. (Or at least make
it look that way syntactically.)

So in Kotlin you can do this:

    
    
      fun String.toLeetSpeak(): String {
         val charmap = mapOf('e' to '3', 'l' to '1')
         return this.map { charmap[it] ?: it }.joinToString(separator="")
      }
    
      fun main(args: Array<String>) {
          println("Hello!".toLeetSpeak())
      }
    

...whereas in Java you would have to change (and have access to) the
implementation of one of the classes or interfaces that String inherits from.

~~~
bad_user
> _...whereas in Java you would have to change (and have access to) the
> implementation of one of the classes or interfaces that String inherits
> from._

Or, you know, just define a plain function.

> _which allow you to add new methods to any class without needing to modify
> the original class_

No, those aren't methods, because they don't do dynamic dispatch. This is
actually a problem in case you have an inheritance hierarchy and you want
different behavior for a _ChildClass_ extending a _BaseClass_.

Speaking of Scala, it's the only one out of the ones mentioned here that can
do that based on the compile-time time, by letting you define the same
extension for both _ChildClass_ and _BaseClass_ , but with different
priorities, such that the compiler can disambiguate.

~~~
ptx
> Or, you know, just define a plain function.

My comment was about extension methods and how the name refers to different
features in Java and Kotlin, so I meant "...whereas in Java [if you wanted to
use the Java feature to do the same thing the Kotlin feature by the same name
does] you would have to ...".

> those aren't methods

I know, they're only sugar for static methods, as I said.

~~~
bad_user
Right, and I was pointing out that your comment doesn't make much sense.

------
bitmapbrother
From the Androiddev reddit

[https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...](https://www.reddit.com/r/androiddev/comments/5zf1xo/future_of_java_8_language_feature_support_on/dey3jzj/)

>I'm guessing the same API restrictions will apply as before? So lambda
expressions, method references and type annotations will be available for
every API level (so no more retrolambda, or maybe still for try-with-
resource?), but other Java 8 features like default and static interface
methods and streams are still only for 24 and up?

>>Yes, this is correct -- we are currently matching Jack's feature set. That
means that we support lambdas, method references, type annotations, and
repeated annotations for every API level; default and static interface methods
are only supported for 24 and up. We are still not supporting try-with-
resources below API 19. Java 8 APIs still depend on the API level since those
are included with the OS (sadly, this means no java.time). For anyone
interested, the source code for the Java 8 compatibility tool, which we call
Desugar, is here:

[https://github.com/bazelbuild/bazel/tree/master/src/tools/an...](https://github.com/bazelbuild/bazel/tree/master/src/tools/android/java/com/google/devtools/build/android/desugar)

------
pianoben
This looks to be "language features" only - so, lambdas, but no Java 8 APIs.
Optionals, streams, etc are not included.

...I hope they fix IntelliJ's default suggestions, which try to turn all of
your loops into `.stream()` calls!

~~~
exabrial
I feel like Google really got bit by "not invented here" syndrome on the
original Android vm :/ using normal JVM bytecodes might have been a good idea

~~~
hota_mazi
It would have been a disaster. The JVM of 2007 would have run crazy slow on
the devices from back then.

Dalvik is the main reason why Android became so popular.

~~~
ptx
Back in 2008 when Android phones were first released, there was a blog post[1]
about Dalvik's (lack of) performance and I decided to try it on my Sony
Ericsson K800i[2], which was released in 2006 and ran Java ME apps (and
miraculously even had an "app store" even though Apple wouldn't invent it
until 2008).

The microbenchmark in the blog post ran in 922 milliseconds on the Google G1
(a.k.a. HTC Dream), or 520 without the assignment in the loop. On my K800i the
corresponding numbers were 190–220 ms and 135–165 ms – although I had to scale
the size of the buffer down from 1228800 to 1100000 elements due to lack of
memory, but scaling the results up by that factor the K800i was still 3–4
times as fast as the G1.

Hardware-wise the G1 should have been much faster. It had an ARM11 at 528 MHz
and the K800i had (I think) an ARM9 at somewhere around or below 200 MHz.

[1]
[http://web.archive.org/web/20091123074004/http://occipital.c...](http://web.archive.org/web/20091123074004/http://occipital.com/blog/2008/10/31/android-
performance-2-loop-speed-and-the-dalvik-vm/)

[2]
[https://en.wikipedia.org/wiki/Sony_Ericsson_K800i](https://en.wikipedia.org/wiki/Sony_Ericsson_K800i)

~~~
signal11
Hey, a fellow K800i owner! I loved that phone, used to run Gmail on it (J2ME
app). For its time it also had a pretty good camera. As far as I remember it
didn't have a headphone jack though, just some weird proprietary headphones.

------
future1979
Tldr for newbie? What is jack all about? I thought android had moved away from
dalvik to art in lollipop. In nougot, I thought android was going to use
openjdk in some parts. Can anyone knowledgeable shed light?

~~~
izacus
ART and Dalvik are VMs that run on your phone. They're a different
implementation of a JVM you know from desktop systems and run a special (non-
desktop Java compatible) DEX bytecode format.

This is about the toolchain. The standard Android toolchain uses standard
OpenJDK/Oracle JDK Java compiler to compile your app code into standard java
class files and then uses dex tool to translate that bytecode into Dalvik/ART
DEX bytecode.

Jack toolchain was all about replacing this javac -> dex step with a single
fast compiler which would also support more Java 8 features and translate them
into DEX format while taking into account feature limitations of ART/Dalvik
runtime. The downside was that it didn't support bytecode manipulation tools
(tools that work on Java class files before they're translated into dex
format) and annotation code generators. Since a lot of good Android libraries
rely on annotation generation that was a pretty huge deal breaker.

This news is about Google abandoning the Jack project and retrofitting the
improvements and partial Java 8 feature support into current toolchain.

------
akent
When they say "into the current javac and dx set of tools" what are they
meaning there? How will they do that exactly? I thought the whole rationale
for Jack was it was a clean break from Sun / Oracle Java and entirely open
source.

~~~
agentjj
>How will they do that exactly?

Presumably they could have the dx tool in the current toolchain support Java 8
bytecode .class files as input (just as the Jill linker in Jack toolchain
allows).

>I thought the whole rationale for Jack was it was a clean break from Sun /
Oracle Java and entirely open source.

In the current toolchain you do something like the following: java sources ->
javac -> .class files -> dx tool -> dex file -> ...

(We already have an open javac with OpenJDK by the way, and dx is part of
AOSP, so "entirely open source" was essentially solved).

Part of the idea behind Jack was that by creating a new compiler toolchain
specifically for Android you could have a faster build by jettisoning the
unnecessary .class intermediates and going straight to dex from the sources
(or rather, as it turns out, a pre-dex that goes into a new intermediate .jack
file with other metadata).

------
Cyph0n
Sounds like good news to me, but I'm not sure why this is not getting more
attention. Isn't Java 8 support a huge deal for Android, or am I missing
something?

~~~
izacus
At this point I think any serious shop should be transitioning to Kotlin (just
like iOS shops are transitioning to Swift).

~~~
pjmlp
Swift is officially an Apple language.

While Kotlin is nowhere to be seen on Android SDK and Google is officially
silent on its use.

This matters a lot to customers IT departments, writing the set of delivery
languages on their Requests For Proposal to consulting companies.

~~~
izacus
Ruby, Python, JavaScript, Java and others also aren't "official Google",
"Apple", "Microsoft" languages and they still run the whole web. It really
question the brokenness of a company processes that refuses to use good
tooling just because a corpo didn't tell them to.

Kotlin is full interoperable with Java APIs and libraries and at this point
there's really very few cases where it's not a significantly better choice for
Android development.

~~~
nradov
That's true for now. But there's nothing stopping Google from making changes
to Android which break Kotlin support in ways we could never predict. From
that standpoint, Java seems much less risky if you're building a large app
that you expect to have to maintain and support for years to come.

~~~
SureshG
> But there's nothing stopping Google from making changes to Android which
> break Kotlin support

It won't, that's what they addressed in this post by ditching jack and
switching back to javac bytecode.

"Over time, we realized the cost of switching to Jack was too high for our
community when we considered the annotation processors, bytecode analyzers and
rewriters impacted."

------
relics443
Well that was unexpected.

I'm assuming they'll translate bytecode for older API versions? Or will Java 8
only be available for newer API versions?

~~~
lern_too_spel
Are you expecting anybody from the Android team to explain themselves? They've
been answering every question about Java 8 with "no comment" for years. They
didn't even discuss Jack/Jill's relation to Java 8 support when the tooling
was announced, and external developers had to figure out Android's plans on
their own from what they could decipher from the architecture.

~~~
bitmapbrother
Well, when you have an ongoing lawsuit with Oracle you have to careful of what
you say in public.

~~~
pjmlp
They are the ones to blame for it.

Apparently every other commercial JVM vendor doesn't have any issue to comply
with licenses, while offering their own changes to Java stack.

IBM, MicroEJ, Atego, just to cite three examples out of many.

~~~
AnimalMuppet
Um, do you realize that those licenses prohibit using it on a phone, because
Sun/Oracle wanted to protect JavaME? So what you're asking for is for Google
to not do Android, and then they wouldn't have the problems that they're
having doing Android. That's... not a useful suggestion.

~~~
pjmlp
Google could use them on the phone, they just needed to PAY Sun just like
everyone else, but of course they wanted to have the cake for free.

~~~
AnimalMuppet
Given that APIs can't be copyrighted, why shouldn't they have that particular
cake for free?

(Actually, the current court ruling is that APIs _can_ be copyrighted, but re-
implementing them is fair use. My personal IANAL opinion is that that won't
stand - it will either turn into "APIs can't be copyrighted" or else into
"APIs can be copyrighted, and the copyrights are not worthless - you can't
copy it and have it be fair use". We shall see. Nevertheless, at the time
Google copied the API, the assumption in the whole industry was that an API
could not be copyrighted. Your statement that Google "wanting their cake for
free" carries a tone of moral criticism that is unwarranted by the
circumstances.)

------
gens
How about support for C ?

~~~
js2
Android has long supported C/C++ via JNI and the NDK.

