

The Upcoming Jack and Jill Compilers in Android - ismavis
https://www.saikoa.com/blog/the_upcoming_jack_and_jill_compilers_in_android

======
desdiv
Interesting enough, Google chose to build upon the Eclipse java compiler
instead of Sun/Oracle's javac. I'm guessing this is due to javac being GPL and
the Android SDK being Apache License 2.0.

This is strangely reminiscent of Apple's strong backing of LLVM.

More competition and corporate funding in the compiler scene is always a good
thing.

~~~
ibrahima
Perhaps I don't pay attention to these things enough (or haven't seriously
worked in Java in a while) but to me it was interesting simply to find out
that Eclipse has its own Java compiler instead of using javac.

~~~
e12e
For me too :-) I'm guessing, it's a reference to this:

[http://eclipse.org/jdt/core/](http://eclipse.org/jdt/core/)

See also:

[http://stackoverflow.com/questions/3061654/what-is-the-
diffe...](http://stackoverflow.com/questions/3061654/what-is-the-difference-
between-javac-and-the-eclipse-compiler)

------
lnanek2
Really bad news for strong Java shops and developers. This move away from Java
byte code probably means very little hope for Java 8 compatibility in Android
any time soon. For myself, I wrote Java server code for a decade before
writing Android apps and the companies I work at often have an order of
magnitude more Java server programmers than Android programmers, if they have
any Android devs. So more compatibility and feature parity with Java proper
would have been great.

~~~
lern_too_spel
I don't follow. What does this have to do with reducing the possibility of
Java 8 compatibility?

One advantage the Jayce development seems to provide is the possibility of
optimizing Dalvik bytecode output based on data that is hard to recover from
Java bytecode but present in the Java source. Secondarily, there may be build
time improvements, but build times aren't C++ bad.

But my best guess at why they did this is to support Java 8 on older devices.
Without Proguard in the build system, they would have to include the entire
Java 8 class library subset they plan to support in every build, resulting in
massive distributables. By building Proguard into the base build system, they
can include just the part of Java 8 that is necessary for the app. Jayce
likely has some features that make the Proguard tasks easier.

I'm speculating far beyond the OP here.

~~~
pjmlp
> I don't follow. What does this have to do with reducing the possibility of
> Java 8 compatibility?

Nothing, assuming Google cares to implement invokedynamic support.

------
bobajeff
If ART is based off of the llvm toolchain how easy would it be to create a C++
frontend for it?

~~~
Tloewald
Or a native backend?

~~~
pjmlp
ART is a native backend.

------
GuiA
Is the name a reference to the (reportedly) terrible Adam Sandler movie, or
something else? And if the former, why?

~~~
seabrookmx
The terrible movie and the toolchain both reference a common folktale:

[http://en.wikipedia.org/wiki/Jack_and_Jill_%28nursery_rhyme%...](http://en.wikipedia.org/wiki/Jack_and_Jill_%28nursery_rhyme%29)

