6 ms·
This is the version of Scala that breaks compatibility with Java 6 in the generated bytecode, by making use of Java 8's features, like invokedynamic, default in
by bad_user 10y ago
This is the version of Scala that breaks compatibility with Java 6 in the generated bytecode, by making use of Java 8's features, like invokedynamic, default interface methods and integration with SAM types.
This is great because the generated bytecode is smaller and more resistant to binary compatibility issues. Scala has had problems with binary compatibility because its features don't map that well on top of the JVM and traits have been very problematic, so thankfully now we have a more efficient encoding. Having SAM support is also good for both Java devs wanting to use Scala libraries and for Scala devs wanting to use Java libraries.
But this also means that Scala 2.11 should be a long-term support version, because even though Java 6 and 7 have reached end of life, the world is not ready to fully commit to Java 8, as sadly there are projects like Android that are holding us back.
Scala 2.12 is a big achievement, with many changes under the hood. I'm happy to finally see it released. Kudos to those involved.
- nothrabannosir 10y ago..., the world is not ready to fully commit to Java 8, as sadly there are projects like Android that are holding us back. And GAE standard environment. :(
- pjmlp 10y ago> the world is not ready to fully commit to Java 8, as sadly there are projects like Android that are holding us back. This is only going to get worse after Java 9 and 10 get released. I imagine by the time we get Java 10, Google might be considering to eventually cherry pick Java 9 features. They just forked the whole eco-system, and lots of people blindly post links to their Java 8 references, without looking into Android source code, where they are just cherry picking Java 8 features, JVM bytecodes and libraries.
- bad_user 10y agoWell I was against Oracle suing them with their copyright and patents and I still am, but Google did fragment the Java ecosystem and should be blamed for it. They just pulled an embrace, extend, then fuck it up. I can understand why they wanted to bootstrap their stuff on top of Java, but now they are clearly not committed to keeping up. And with all of their resources, I just won't believe they can't do it.
- nine_k 10y agoThis is why both Scala and Kotlin make a lot of sense for Android development.
- pjmlp 10y agoTrue, but I think Kotlin has an edge here. JetBrains, as Kotlin steward, takes an effort to have Kotlin work painlessly within Android Studio. The Scala support for Android apparently only works properly within InteliJ, which means a few versions behind what Android Studio actually supports. It also requires much more configuration steps.
- the_af 10y agoRegardless of Kotlin (which I don't feel inclined to learn at this point), would you say Scala is usable for Android development? I'm about to start a personal project and would love to use Scala if possible. Note: by "usable" I mean really usable, not "it works, but with lots of caveats and extreme pain" :)
- simono 10y agoIn my experience it is. The sbt-android plugin is really amazing. It makes compiling with ProGuard enabled as fast as Gradle without ProGuard, due to the plugins integration of incremental compilation with ProGuard. Plus, there are quite a few built-in features and "add-on" plugins which enhance the experience further (sbt-android-protify, sbt-android-gradle). A bunch of people built an "official" website around Scala-on-Android recently, scala-android.org. If you have any questions drop by in the Gitter channel: https://gitter.im/scala-android/sbt-android https://gitter.im/scala-android/sbt-android
- the_af 10y agoQuestion: I'm about to start a hobby project on Android. I use Scala in my day job and strongly prefer it to Java. How would you rate its usability (coding, testing, debugging, performance) for Android development? Ideally I don't want to be fighting the tools, I just want to hack stuff in Scala and have it work on Android. If all else fails, I'll revert to Java 1.6, but I'd rather not.
- paulddraper 10y agoWeird to blame current Scala versions for not supporting end of life versions. You can still use Java 6 and Scala 2.11. It's just that Java 6 will not receive any bug fixes or security updates, and Scala 2.11 will not either. But both will continue to work. Seems very sane to me.
- bad_user 10y ago> Weird to blame current Scala versions for not supporting end of life versions. I didn't. > will not receive any bug fixes or security updates, and Scala 2.11 will not either Oh, I'm pretty sure that Scala 2.11 will receive fixes, security updates and even backports of features for a very long time. For example SI-2712 is getting back-ported to Scala 2.11.9 and there's even talk of back-porting it to Scala 2.10.
- paulddraper 10y agoThe last announced plan was to conclude 2.11.x with 2.11.9 (currently at 2.11.8). Maybe we'll see longer support for people who don't migrate (heck, SBT still uses 2.10.x), but justifying it by Java version is weird. If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions.
- adriaanm 10y agoYep, 2.11.9 is the last planned release, but we would release another one for security fixes or anything as severe. If we get customer requests for backports, we (usually) also release those publicly. Thanks for your support!
- lmm 10y ago> If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions. No, because Scala doesn't offer forward binary or source compatibility. Maintainers of widely-used Java libraries can write and build for Java 6 and be confident their libraries will be usable by everyone (on Android and off). Maintainers of widely-used Scala libraries have no such option (for now they can write their code using the subset that works in Scala 2.11 and 2.12 and cross-build, but there's no guarantee that such a subset will be maintained in 2.13 and beyond).