Future of Java 8 Language Feature Support on Android | Hacker News Reader

Future of Java 8 Language Feature Support on Android

android-developers.googleblog.com

182 pointsBrianHV99 comments

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

[2] http://stackoverflow.com/questions/35958814/how-jack-java-an...

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

> Is Java source code going to be the only common currency between the Java 8 and Android ecosystems?

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.

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

Right on the spot, yet as Silicon Valley darling they get a free pass instead of being blamed like Microsoft was.

I still hope Oracle manages to force them to play by rules.

Other JVM vendors like IBM, Atego, Azul, MicroEJ,.... are able to provide their own extensions, while supporting Java properly and not forking the whole language + standard libraries.

Some of them do sell JVMs for embedded devices with soft and real-time constraints much higher than Android, so the whole story about a Java fork being a requirement for Android is such Google marketing for their actions.

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.

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.

Kotlin has generics that are in most circumstances reified enough ;).

Optionals of Java8 and Guava are a terrible idea. @Nullable is just an annotation. Null-safety built in the language is the only way to go.

You could always argue that a language is just cleaner syntax. Kotlin is a cleaner syntax for interacting with JVM-bytecode. Scala is a also cleaner syntax for interacting with JVM-bytecode. JVM-Bytecode is a cleaner syntax for interacting with operating systems.

Optional is a concept that you need even in a null-safe language (e.g. Haskell has Maybe). With language-level nullability you can sort-of emulate a pseudo-Optional type, but why would you want to? It's inherently second-class because it can't ever be properly compositional (Option[A] is always a different type from A and can be understood without knowing anything about A, whereas A? might or might not be a different type from A, you can't understand what it does without knowing the details of what A is).

Once you start interacting with JVM bytecode Kotlin ceases to have null-safety. @Nullable is just an annotation but at least you can write it down, unlike Kotlin's "platform types". Conversely if you're not interacting with non-Scala bytecode then Scala is null-safe in practice if not in theory, because the Scala ecosystem doesn't use null and has tools to enforce this.

I think it most real code you're better off without the Optional monad.

A variable being null is not a condition you can always a have a name for. You want to use it sometimes, but not built your entire vocabulary around it.

You also don't usually want to pass wrapped nulls around, you just want nulls available in local state.

> You want to use it sometimes, but not built your entire vocabulary around it.

Sure, which is why it should be an ordinary library type written in the language (and operated on with normal methods), not a magic special type with direct compiler support and custom operators.

> A variable being null is not a condition you can always a have a name for. You want to use it sometimes, but not built your entire vocabulary around it.

> You also don't usually want to pass wrapped nulls around, you just want nulls available in local state.

Why are you thinking in terms of "null" and "wrapping"? Think in terms of the business condition you want to represent. Often you have the possibility of some value being not-set or unknown in your data model - this comes up often enough that it's worth having a standard library type to represent it. "A variable being null" is not something that happens a priori, it's just an unfortunate representation certain languages adopt.

> Kotlin has generics that are in most circumstances reified enough ;).

They are not more reified than what you can achieve by just putting Class<T> fields in Java objects to represent the runtime type of the generic type parameter. Sure, Java solution is kinda more verbose and ugly, but this is basically what people already said here: Kotlin has some nice syntax sugar.

But you still can't have two different methods differing only with the generic type parameter (e.g. List<String> and List<Integer>). And the code is still not-specialized properly, read "slow".

Real reification will be possible if project Valhalla arrives (maybe Java 10, who knows?)

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.

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

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

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

Also in Kotlin you can have extension methods with multiple receivers:

    class Dictionary {
       val wordList = setOf<String>()

       fun String.isWord(word): Boolean = 
          word in wordList
    }

    ...

    val myDictionary = Dictionary()
    
    with (Dictionary) {
        println("dog".isWord)
    }

    (you can skip the "with" when being inside Dictionary)

The @Nullable syntax is akin to putting a band-aid on a rotting leg. You cannot fix Java without breaking compatibility with older code. They only way to see it is not to look at the problem from the inside out when you have been surrounded with Java for perhaps decades in your career.

In my code null-pointer exceptions or similar accidents (force unwrapping something that simply doesn't exist) never happens anymore. Not in my libraries and not in my program code. A whole class of bugs just gone. Simply because I have to prove that something exists before I use it at compile time already.

It's like having security that starts with everything turned OFF for a default user instead of ON.

If Kotlin wasn't just CoffeScript for Java but a whole new language then there would be no reason to use it instead of Scala. There's an excluded middle here: either it's a very-close-to-Java language (in which case probably not worth the cost of using) or it's a language that's significantly different from Java (in which case it has no interop/familiarity advantage over Scala and the two languages have to be compared on their merits - and I'd say Kotlin comes off pretty poorly in that).

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

Sure. I do exactly that in Scala too.

One of the arguments against Scala is that its large and simply too feature rich. https://agilewombat.com/2016/02/01/scala-vs-kotlin/

The parts it does add are small and orthogonal. They can be combined to make surprising things, but that's the mark of a good language - it lets people write very complex libraries, but by combining simple features in ways that make sense.

Specifically, call by name is highlighted in the IDE these days (though I agree we would be better off without it), implicit parameters are really important and it's not hard to ensure consistency, for comprehension is the opposite of what that site is saying (dealing with multiple monads is a lot harder without it, and it's not like ignoring monads as Kotlin does makes the problems you need monads for go away), and the rule about operators is incredibly simple (your method name is just your method name, if you want to write a "" operator you call it "" rather than having to remember what the magic name for overloading that is).

Meanwhile your link ignores the many complex features in Kotlin e.g. delegation, platform types. Maybe they were added since it was written - Kotlin seems to add a lot of ad-hoc features very quickly.

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

Kotlin is a smaller language than Java (just based on my feeling actually) yet more safe and in many regards flexible. Kotlin is more similar to Swift, where Swift is aimed at Cocoa and Kotlin at the JVM.

The only thing it really has in common is that it uses the JVM. But F# is not similar to C# just because it has .Net compatibility. Especially if you try to write C# in F# instead of F# according to the gospel.

Just as I've seen tons of code by Objective-C devs that's just the old code translated to the new code a lot of Java devs probably won't really get Kotlin and will write the same code as they would do in Java.

I actually clicked on the link with the faint hope that there would be something in the announcement about Kotlin.

Google support for Kotlin, or some initiative to get a grip on security updates are the only announcements that I really want to see about Android at this point: I use an Android phone, but there's no end-user things that I feel that it lacks right now. IMO, the significant weaknesses of the platform are updates and developer experience.

Why would Google have to announce anything about Kotlin? Do you wait For Apple to announce something about Python before using it on your mac?

(We're running Kotlin in production for a long while now and at this point I think starting development of an app in Java is rather silly considering how stable and nice Kotlin is.)

Our customers do, if it isn't a vendor supported language on platform X, usually their IT doesn't allow it on their list of languages for project delivery.

Are they the kind of folks that demand that you use .NET or C++ on Windows? I had a colleague like that. I had to explain to him that people are actually using Java or Python in production, on Windows.

Depends on the customer, but yes that is usually the case.

I'm unable to convince my employer to use Kotlin. Having Google put their weight behind it would tremendously help that situation.

Exactly right. Only in La La Land Google would ignore their own languages like Dart and Go and go on to officially support some random JVM language.

Google has no interest in providing the right support for Java developers it seems.

Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement.

And of course, lack of many of the SE APIs in any case.

The fun of writing portable libraries between Java and Android Java is only getting better.

Now that Xamarin is open source, a reasonably stable Java bytecode -> Xamarin-compatible CIL cross-compiler could be pretty useful. It would also solve the problem of varying VM quality between Android versions (especially around the Dalvik to ART transition).

I don't feel the pain of lack of modern Java support that much, because I spend most of the time on NDK, but there the tooling support also leaves a lot to be desired, like partial STL support or the whole story regarding build infrastructure.

Xamarin looks a nice proposal out of this mess and as a JVM/.NET/C++ consultant, with focus on native apps, I have been looking into it as possible alternative.

I think their legal shenanigans regarding usage of Java technology plays a major role here: they simply do not own Java technology. It was a horrible mistake to use it without Sun's/Oracle's approval and as soon as the first lawsuit ends in favor of Oracle, they will be milked to an extent that has not yet been seen.

Every other commercial JDK vendor is able to comply with licenses and still provide language extensions and their own VM stacks. There are quite a few examples to chose from.

Why should Google be a special snowflake that doesn't play by the same rules?

Well that special snowflake is sued and they are having their day in court. Oracle has extinguished many rivals in court and maybe they will do it again.

Why should they have to play by the same rules? If the rules they are playing by are judged to be legal, what's wrong with what they're doing?

To avoid doing a Microsoft move on us that now enjoy the pain of writing not so portable Java code across official standar Java™ and Android devices, thus making a fork in the Java ecosystem.

First, Oracle's legal theories have not held up very well in court.

Second, Oracle has explicitly said that OpenJDK is OK, and Google has shifted to an implementation based on OpenJDK.

So I wouldn't hold my breath for your prediction coming true...

> Google has shifted to an implementation based on OpenJDK.

No they have not, just go look at AOSP source code.

Yes they are using it instead of Harmony nowadays, but they are cherry picking features and APIs, instead of providing 100% compatibility with the language standard.

This is the exact opposite of what I got from reading this blog post... Jack is what did the bad stuff you are talking about, Jill was (apparently: I hadn't read much about it before today) a mitigation for that badness (by allowing you to "link" in .class files), and they finally decided to throw all that away and go back to actually (correctly, in my book) supporting the old javac->dx flow (which guarantees that if they are going to support Java 8, and this blog posts claims they are intending to do so, that they do it by supporting the bytecode correctly, as now all source code has to go through this path and the Java ecosystem of code transformers will continue to work as expected).

My impression from the post was that they were going back to the old (standard) way of letting the standard javac compile Java to bytecode and then letting dx convert it to Dalvik bytecode, but now with the addition of Java 8 bytecode support in dx. Their stated reason is precisely what you bring up: compatibility with tools that work with the bytecode, like the Scala compiler.

Is this impression incorrect? Are they doing something special with the Java source code instead of processing the byte code? Are they doing their own javac compiler?

At second glance it looks like you're right. When they say "add support for Java 8 language features directly into the current javac and dx set of tools" I read that as directly adding Java 8 language support into the javac already in the toolchain, but the comment bitmapbrother quoted links to a tool that operates on Java 8 bytecode[1]. I guess they are adding Java 8 bytecode translation as a part of dx or as a build step between javac and dx.

If they aim to translate all valid Java 8 bytecode (and not just classes emitted by javac) then the situation is at least as good as we would have got with Jill.

[1] "Command-line tool to desugar Java 8 constructs that dx doesn't know what to do with, in particular lambdas and method references." https://github.com/bazelbuild/bazel/blob/master/src/tools/an...

IMO having Android VM fully compatible with Java 8/9/10 is a non-realistic dream considering what Google is doing now :/

It never was, even the adoption of OpenJDK is a marketing gig, as they are actually cherry picking features, as anyone reading the AOSP source code history can validate.

>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

To quote the article: "We've decided to add support for Java 8 language features directly into the current javac and dx set of tools."

The way I'm reading that could (maybe) work, the regular toolchain (javac -> .class files -> dx -> dex file) would get an upgraded dx tool that could take classes with Java 8 bytecode as input. In that case something like Scala (or any compiler that outputs Java 8 bytecode classes) would be just as well supported.

From the Androiddev reddit

https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...

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

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!

You can turn that on and off in the settings in IntelliJ already, and it only enables that suggestion if you're using a Java 8 JDK.

If it is suggesting it on a correctly configured Android project, I suspect you found a bug.

Just turn them off or use Android Studio, which I believe still has sane defaults. Help file on this: https://www.jetbrains.com/help/idea/2016.3/disabling-and-ena...

Also, if looking for APIs, and willing to risk having to tweak code later, there are a few "polyfills". For example: https://www.google.ca/amp/s/barta.me/enable-java-8-features-...

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

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.

Every feature phone on the planet used to run Java ME without any problem. Dalvik may have had some optimisations, but to claim Java would have run "crazy slow" is unlikely to be the reason Google chose the implement their own VM.

JavaME was a total disaster of incompatibilities, lack of any useful API and broken platform support.

The fact that you can use a lot of standard Java libs with Android was and is a huge boon that makes development significantly easier than the hell that was JavaMe.

I guess you never had the fun to port Android code among OEMs, using OEM specific SDKs for specific features like real time audio, or work around firmware bugs specially on Samsung devices.

Android fragmentation is no different than J2ME used to be.

> Android fragmentation is no different than J2ME used to be

That has to be hyperbole: no one who ported J2ME apps would say what you did with a straight face. Even a run-of-the-mill app with no esoteric features would need to be ported because Nokia's methods had different signatures to SonyEricsson's for text fucking rendering, because why not. The entirety of J2ME an "OEM specific SDK" This is before considering MIDP, CLDC versions and goddamn model-specific processor and memory differences. "Android fragmentation is no different than J2ME used to be" my ass.

There was this thing called LWUIT and Sony supported Nokia extensions.

> no one who ported J2ME apps would say what you did with a straight face. > This is before considering MIDP, CLDC versions and goddamn model-specific processor and memory differences. "Android fragmentation is no different than J2ME used to be" my ass.

How is Android any different? Should I start listing differences among devices here?

> Android fragmentation is no different than J2ME used to be.

This is a huge overstatement. J2ME was fragmented in things like basic UI with no tooling to handle it. In Android you really need to dig into hardware-specific funcionality (or really really mess up UI design) to be severely affected by the fragmentation.

Try to use the SupportLibrary in Samsung devices, or better yet, check the code for device specific workarounds.

No, Android became popular due to the Google loving hipsters that believed in FOSS and AOSP, and OEMs that just love getting an OS for free with almost no strings attached.

Every other commercial Java vendor in this planet doesn't have any issue using standard Java tools, compiling with Java licenses and deliver JVMs able to run in embedded devices with soft and hard real time constraints.

Google for all their might is a special snowflake not able to do what the rest of the Java world is capable of.

This sounds strange. Seems Next you will start claiming that Oracle DB is popular because Oracle loving hipsters like paying for heavy licensing fee and support and not because it is high performance DB for critical enterprise requirements.

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

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

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.

Dalvik has nothing to do with Android's popularity. Android's popularity is caused by.

1. Price - you can buy an unlocked Android device for $50.

2. It is free to manufacturers

3. No alternative for phone manufacturers at first. By the time Windows Phone git good enough, it was too late.

AFAIK they did this to 1) improve runtime link/startup times (so, a similar reason why many other mobile devices have their own class file formats; for more information, read my introduction to the subject, linked below), and 2) to make sure they were not violating various bytecode-related patents from Sun that relied upon a stack machine.

http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0...

1) I don't believe. I'm not talking sun's JVM, just the byte code. We have jvms with super fast boot times already, just not openjdk.

2) interesting. I wasn't aware of these. It would have been useful to get sun involved in the project, but they didn't.

Did you read my article? (Because your comment doesn't seem to bring up any actual rebuttal of the point, which makes me think you didn't, which makes me hesitant to waste more of my time explaining it, particularly as it might make it seem OK to just toss aside arguments with "I don't believe" as the other person will then just do more work in the conversation.) The problem with bytecode is that it has complex linking and relocation issues. DEX was specifically designed to convert trivially to ODEX, and which hardcodes vtable and field offsets to make interpretation trivial and fast, while also letting the code be memory mapped between processes. FWIW, current versions of Android have expanded the optimization step all the way up to something more like a compiler, but it took them many many years to get to that point. Since you are speaking with someone who is extremely familiar with VM design, as well as the history of the Android project and its unique limitations, would you mind being more specific with what you feel is inaccurate? (I am totally willing to believe I missed something, as I spend way way more of my time on iOS internals, and I am "rusty" with VMs--though not so much that the students I teach to about them notice horribly ;P--but it just doesn't seem like that so far.)

Well, you can hardly add those features onto devices that don't have them in their standard library. Even now all the features that require modification of the runtime are restricted to the VMs actually supporting them (e.g. try-with-resources since Android 4.4, most other new Java 8 features since Android 6.0 I think).

(Yes, it would be nice if new Android versions would expand the standard library).

In the end I don't see that as a huge restriction - instead of java.time there's ThreetenABP, instead of streams there's better RxJava, etc. With added bonus that you're not limited to whatever libraries device ships with, but you bring your own always up to date ones.

Also, right now, any new project should pretty much be started in Kotlin which does everything that Java 8 does better and is bytecode compatible with Android VMs.

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?

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.

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.

So is OpenJDK and DEX tool used right now.

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

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?

They already had something called Jack that let you use java>6 features. It just didn't integrate as well with some parts of the android ecosystem

It would be awesome. There are some polyfilling libraries, like Retrolambda for lambdas, and ones to get streams etc already, without actually using Java 8.

Jack broke a lot of things on Android (like some annotation libraries, which the article mentions), so I think the wider Android community will be happy there's a clear path forward to Java 8.

Enabling Jack also prevented the ability for devs to use Instant Run. It's not a dealbreaker, but combined with all the other broken libraries it definitely added to the frustration with needing/wanting to upgrade to Java 8. I never found it worth upgrading and almost always ignored sample code that showed Jack/Java8 in the gradle files because they didn't seem to be based on real-world usage.

I don't really care, now that I'm invested in Kotlin.

It still seems like good news. If they had decided to focus their efforts on Jack (compiling Java source code directly to Dalvik bytecode) the parts of the toolchain that work with Java bytecode (such as the output of the Kotlin compiler) would have been de-prioritized and might not have been as well supported.

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

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.

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.

It is not the question of telling to, it is the question of accepting to sign the contract at all, or pay at the end.

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.

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

Now you ask, SCADE partners with PerfectlySoft is now release SCADE for beta testing, you can run Swift coding on iOS and Android (Swift or C to JNI support is in their roadmap).

http://scade.io or chat slack channel perfect.ly to chat with the team.

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?

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.

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

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.

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.

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.

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

Perhaps, but I will say that none of them are nearly as juicy of a lawsuit target as Android, which controls like 70%-ish of the multi-billion device smartphone market right now.

James Gosling stated multiple times that the only reason Sun didn't sue Google and Jonathan made that public announcement was the state of Sun's bank account.

Just search for "Google slimmed Sun".

I've moved on to Kotlin. Much more enjoyable for Android development IMO.

Huh, Android team has been explaning themselves around Java 8 issues a lot (look at I/O talks, linked redding thread in another comment here, etc.)

Yeah, it does a similar thing like RetroLambda - things like lambdas are polyfilled and replaced on bytecode level. Some features require newer VMs and I'm afraid standard library won't be expanded with new APIs.

See https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...

How about support for C ?

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

Reply on news.ycombinator.com