Android Studio 3.0 Released With Kotlin Support, Java 8 Features

[bug77]

What will run under Android 4? Perhaps that is the question. If you dismiss Android 4 then : what will run under Android 5?
(all I know is an application I looked up targets Android 4.3 and higher)

About Kotlin I read an interesting thing on a couple web sites or comments, namely that it's a clone of Apple Swift, quite simply. There should be differences of course.

Tru dat. And keeping with tradition (of others copying Apple), Intellij copied Swift in 2011, 3 years before Swift's initial release

[starshipeleven]

Tru dat. And keeping with tradition (of others copying Apple), Intellij copied Swift in 2011, 3 years before Swift's initial release

Looks like we found the ones that can send their CV to the company asking for people with 5 years of Swift experience (when Swift was only 3 years old) then.

Damn russians.

[Michael_S]

About Kotlin I read an interesting thing on a couple web sites or comments, namely that it's a clone of Apple Swift, quite simply. There should be differences of course.

That's impressive, since Kotlin is three years older than Swift.

(Edit) Kotlin didn't go public until a year after Swift, but it was in development since 2011. I don't know if it's officially documented anywhere, but I would call Kotlin a reaction to the Scala language. Scala attempted to be a better, less verbose, more flexible and more functional alternative to Java on the Java Virtual Machine. And it's a great language. But it has these flaws;

- Build times are very slow. The core language developers are working on fixing that, but Scala compiles can take five times longer than Java compiles. Kotlin compiles are 20% or so slower than Java code compiles.

- You can compile Scala code with Maven (the most popular Java build tool), but most projects switched to Scala's own SBT build tool which is difficult to learn and substantially different from Maven. We have a mixed Java/Scala project at work and we gave up integrating the builds into our existing Maven setup and wrote a shell script that invokes SBT for the Scala bits. Kotlin builds fine with Maven.

- Scala allows unlimited operator overloading, so there are lots of libraries with functions like "-->!" and "!*<" and "!!" any other wacky symbol combination you can imagine. Kotlin allows overloading single operators +,-,/,*.

- Scala code can call Java code easily, but you have to do a lot of extra work for your Scala code to be callable from Java. Kotlin calls Java as easily as Scala does and your Java calls Kotlin just as easily.

- Scala has implicit type conversions. Implicit type conversions were a way for developers to add new functions to existing classes in the Java standard library. So I could use that to make a new method in java.util.ArrayList toSet() or something. But people can use implicit conversions in Scala anywhere, so you might read code and see foo.getBar() but the Foo class definition has no getBar() function defined. There was some implicit conversion in scope that added getBar() that you missed. Kotlin has extension methods, which provide the same end feature of adding new functions to another class. But extension method definitions are easier to notice and reason about.

- Scala offers something similar to C++ or Python or Common Lisp Object System style multiple inheritance through something called traits. Reasoning about traits and setting them up properly is difficult. Kotlin offers something similar to multiple inheritance by allowing interface functions to have implementations, and supporting multiple interfaces. If a Kotlin class inherits the same function with the same type signatures from multiple interfaces, the user must explicitly define which version they use or there is a compiler error.

I wouldn't object to using Scala for work. I maintain the lone Scala app at our little company. But I think Kotlin is really Better Scala.

[bug77]

Michael_S My own experience with Scala seems to be a little less painful than yours, but I only take issue with one of the flaws you describe. Namely multiple inheritance. It's weirdly implemented in Scala (use the right-most declaration - a thorough formatter will break that), but multiple inheritance is all but baked into Java since Java 8's default declarations in interfaces.

PS Case classes rock!

[Michael_S]

Michael_S My own experience with Scala seems to be a little less painful than yours, but I only take issue with one of the flaws you describe. Namely multiple inheritance. It's weirdly implemented in Scala (use the right-most declaration - a thorough formatter will break that), but multiple inheritance is all but baked into Java since Java 8's default declarations in interfaces.

PS Case classes rock!

I still strongly prefer Scala to pure Java. I think the benefits outweigh the drawbacks relative to Java by a huge amount. But I've had headaches with SBT at my last job and this one. For example, I had to modify part of the Play Framework build and I used these files as a starting point: https://github.com/playframework/pla...Settings.scala and (hopefully the forums won't eat the link) SBT has operators "**", "*", (neither asterisks are in a mathematical multiply context), "%", "%%" (neither percents are in a modulus context), "++=", "~=", "??" (which is what went through my head when I tried to read these build files), "---", and others.

That's not build tool syntax or a clever DSL. That's line noise when your modem fails.

[bug77]

I still strongly prefer Scala to pure Java. I think the benefits outweigh the drawbacks relative to Java by a huge amount. But I've had headaches with SBT at my last job and this one. For example, I had to modify part of the Play Framework build and I used these files as a starting point: https://github.com/playframework/pla...Settings.scala and (hopefully the forums won't eat the link) SBT has operators "**", "*", (neither asterisks are in a mathematical multiply context), "%", "%%" (neither percents are in a modulus context), "++=", "~=", "??" (which is what went through my head when I tried to read these build files), "---", and others.

That's not build tool syntax or a clever DSL. That's line noise when your modem fails.

Yup, abuse is the most quoted argument against operator overloading. And I guess I was lucky I was able to eschew SBT. Idk how good gradle is with Scala, maybe that could ease your integration pains? Because multi-language projects is definitely when maven reaches its limits.

[uid313]

Yes you should develop in Kotlin over Java. Due to licensing issues, Android's Java is stuck at version 7. So, instead of forking, Google decided to adopt a new language that targets the JVM. It's not a great language but it's better than Java and has some useful features like null-safety that overlap well with the to-native compilation that's to come with Google's future capability-based RISC-V core and OS.

As far as I know Android can target Java 8. First they had the Jack compiler for that, which is now deprecated since they support Java 8 without the Jack compiler now.

You can set "compileOptions" with the "sourceCompatibility" property and the "targetCompatibility" property and set it to 1.6, 1.7 or 1.8.
So I think Android does support Java 7 and Java 8.

And as for RISC-V I don't think there are any high-performance cores coming any time in the future. It seems it will be low-performance IoT applications. You won't see RISC-V in any phone or tablet any time soon.

[c117152]

As far as I know Android can target Java 8. First they had the Jack compiler for that, which is now deprecated since they support Java 8 without the Jack compiler now.

You can set "compileOptions" with the "sourceCompatibility" property and the "targetCompatibility" property and set it to 1.6, 1.7 or 1.8.
So I think Android does support Java 7 and Java 8.

And as for RISC-V I don't think there are any high-performance cores coming any time in the future. It seems it will be low-performance IoT applications. You won't see RISC-V in any phone or tablet any time soon.

The Freedom U500 is targeting the same performance space as the RasPi3 and odroid c2 which is well within contemporary smartphones usage. Look here: https://www.cnx-software.com/2016/07...e-risc-v-socs/ See those "custom accelerators" bit? That's where you shove in the video decoders and the likes. And the "custom instructions" is for hardware supported ciphers. Together, you have a smartphone SoC.

[uid313]

The Freedom U500 is targeting the same performance space as the RasPi3 and odroid c2 which is well within contemporary smartphones usage. Look here: https://www.cnx-software.com/2016/07...e-risc-v-socs/ See those "custom accelerators" bit? That's where you shove in the video decoders and the likes. And the "custom instructions" is for hardware supported ciphers. Together, you have a smartphone SoC.

Oh, that's pretty cool. I didn't know about the U500 it is much more powerful than I thought. I thought the RISC-V processors that existed or were under development were very weak ones like single-core 300 MHz.

This one is 1.6 GHz which is quite nice. But not only does it need to be comparable to Raspberry Pi 3 in performance, but also in price, energy efficiency and power consumption.

Perhaps it could make a nice single-board computer but still a long way from appearing in any phone since it needs a SoC with GPS, Wi-Fi, 4G/LTE, Bluetooth, NFC, GPU, DSP, ISP, audio, camera, etc.

Also Raspberry Pi 3 has lots of competition such as Dragonboard, Banana Pi, etc.

It is a very very long far away from a Snapdragon 845, or even a old Snapdragon 820.

[c117152]

This one is 1.6 GHz which is quite nice. But not only does it need to be comparable to Raspberry Pi 3 in performance, but also in price, energy efficiency and power consumption.

It should be better. It's the same cache size but has no legacy wasting silicon so, beyond the obviously better branch prediction made possible with modern ISA designs that ARM is missing, you can stick bigger and better accelerators.

Perhaps it could make a nice single-board computer but still a long way from appearing in any phone since it needs a SoC with GPS, Wi-Fi, 4G/LTE, Bluetooth, NFC, GPU, DSP, ISP, audio, camera, etc.

Actually those are the easy parts since you just license those and stick them on the lanes. The problem is the software. Between the compiler work and the kernel drivers, any new core designs - especially ones using a new ISA - are years from the market. Well, we're a few years into this so RISC-V is further along then years' worth... But still, software :/

Also Raspberry Pi 3 has lots of competition such as Dragonboard, Banana Pi, etc.

It's not really competition seeing how the RasPi is a non-profit and the odroid clearly performs better in all benchmarks while retaining the same interfaces... Still, yeah SBCs aren't really a comfortable market to compete in seeing how most SoC manufacturers consider it a dumping ground for under-selling hardware or a niche for fellow programmers.

It is a very very long far away from a Snapdragon 845, or even a old Snapdragon 820.

Hard to say. A lot of that is just GPU. And that's license-able.