8 ms·

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 promis

by dkarl 10y ago

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-android-compiler-kit-will-affect-scala-developers http://stackoverflow.com/questions/35958814/how-jack-java-an...

makeramen 10y ago
Kotlin is committed to Android support though, and the community is coming to rally behind it much more than Scala.
- glibgil 10y ago
  > Is Java source code going to be the only common currency between the Java 8 and Android ecosystems?
- bad_user 10y ago
  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.
  - pjmlp 10y ago
    > 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.
  - cel1ne 10y ago
    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 10y ago
      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.
      - cel1ne 10y ago
        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.
- sjellis 10y ago
  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.
  - izacus 10y ago
    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.)
    - pjmlp 10y ago
      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.
      - oblio 10y ago
        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.
        pjmlp 10y ago
        Depends on the customer, but yes that is usually the case.
    - agildehaus 10y ago
      I'm unable to convince my employer to use Kotlin. Having Google put their weight behind it would tremendously help that situation.
pjmlp 10y ago
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.
- johncolanduoni 10y ago
  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).
  - pjmlp 10y ago
    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.
- _pmf_ 10y ago
  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.
  - pjmlp 10y ago
    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?
saurik 10y ago
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).
ptx 10y ago
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?
- dkarl 10y ago
  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/android/java/com/google/devtools/build/android/desugar/Desugar.java https://github.com/bazelbuild/bazel/blob/master/src/tools/an...
izacus 10y ago
IMO having Android VM fully compatible with Java 8/9/10 is a non-realistic dream considering what Google is doing now :/
- pjmlp 10y ago
  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.
agentjj 10y ago
>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.

by dkarl 10y ago

makeramen 10y ago

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

glibgil 10y ago
> Is Java source code going to be the only common currency between the Java 8 and Android ecosystems?
bad_user 10y ago
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.
- pjmlp 10y ago
  > 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.
- cel1ne 10y ago
  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 10y ago
    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.
    - cel1ne 10y ago
      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.
sjellis 10y ago
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.
- izacus 10y ago
  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.)
  - pjmlp 10y ago
    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.
    - oblio 10y ago
      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.
      - pjmlp 10y ago
        Depends on the customer, but yes that is usually the case.
  - agildehaus 10y ago
    I'm unable to convince my employer to use Kotlin. Having Google put their weight behind it would tremendously help that situation.

pjmlp 10y ago

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.

johncolanduoni 10y ago
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).
- pjmlp 10y ago
  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.
_pmf_ 10y ago
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.
- pjmlp 10y ago
  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?

saurik 10y ago

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

ptx 10y ago

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?

dkarl 10y ago
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/android/java/com/google/devtools/build/android/desugar/Desugar.java https://github.com/bazelbuild/bazel/blob/master/src/tools/an...

izacus 10y ago

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

pjmlp 10y ago
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.

agentjj 10y ago

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