6 ms·

Nice new language features for Java users! sobs in Android-Java8

by dbrgn 4y ago

nine_k 4y ago
Android? Why not Kotlin then?
- waynesonfire 4y ago
  Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for.
  - cies 4y ago
    > Kotlin was designed to replace Java 1.6 and that's about all it's good for. Not sure what K was designed for. But we use it to fix J's billion dollar "implicit nulls" mistake, and terse syntax (making it useful for templating: Kotlinx.html), and pass-as-value method references. We love it's hang towards immutability. K is not Haskell, but it sure feels a lot safer that J (where a lot of strings were used to refer to methods, and strings+Groovy was used to do templates). Bottom line: I'm too old --and life's too short-- for NPEs.
    - flatiron 4y ago
      Have your tried static analysis? When I used Java most (if not all) of our NPE problems were pointed out by sonar qube
      - ris58h 4y ago
        What if I don't want to put @Nullable/@NotNull all over the code?
        seer-zig 4y ago
        Can't you setup your project to be `@NotNull` by default, and explicitly mark @Nullable fields? Those should be more rare anyway.
      - cies 4y ago
        Yes. But coupled with our Groovy templates (that we're now moving to Kotlinx.html) it did not really help much. This is not Java's problem per se (though one could argue that J's verbose syntax prohibits it for in-code HTML templating)
      - hn_throwaway_99 4y ago
        Ugh, to hear what hackarounds folks have to deal with in the Java ecosystem is kind of frightening. I moved from Java to Node (then Typescript) about 8 years ago. Moving to a language that doesn't allow implicit nulls makes a world of difference, importantly, at "programmer" time, not just build time. That is, when programming in VSCode, I immediately get feedback if I attempt to use a nullable variable in an unsafe manner. That has huge productivity benefits compared to if I only got that feedback after my build ran. Similarly, simple things like safe optional chaining (i.e. foo?.bar?.baz) makes code so much faster and easier to write, and AFAIK this hasn't been added to Java yet (correct me if I'm wrong).
- nradov 4y ago
  Kotlin is certainly a good general purpose language. But many developers would prefer to be able to use Java for Android development including the excellent tool chain and numerous libraries. It's a shame that commercial disputes between Google and Oracle have left us with this fragmented platform.
  - Strum355 4y ago
    > the excellent toolchain and numerous libraries The same libraries that can be used from Kotlin?
    - pjmlp 4y ago
      Only if they can be usable from ART capabilities, and desugared into DEX opcodes.
  - cies 4y ago
    > the excellent toolchain and numerous libraries The toolchain in both cases is basically IntelliJ (rebranded as Adroid Studio)
  - pjmlp 4y ago
    Kotlin is still heavily dependent on Java ecosystem, so this excuse is nonsense, there is hardly any Kotlin without Java. See how sucessfull Kotlin/JS and Kotlin/Native are on the wild.
  - Alupis 4y ago
    Give Kotlin an honest try. I think you will be impressed... and that's coming from a crusty old curmudgeon "get off my compiler" java fanboy.
- tut-urut-utut 4y ago
  Why learning a whole new language just because vendor refuses to upgrade? At that point one could also say "why Anrdoid?".
  - wlpu 4y ago
    Because you can use the same toolchains, APIs, libraries, and even progressively migrate with both languages in the same project. Honestly, people who whine about Java 8 in Android and refuse to consider Kotlin are suffering by choice.
    - pjmlp 4y ago
      Only those that can be desuagared into Android Java, everything else will fail to either compile or map into ART features.
      - kuschku 4y ago
        All of Kotlin runs fine on Android, that's its point, that all of it can be desugared to run on a 1.6 or 1.8 JVM?
        pjmlp 4y ago
        If you don't want to use modern Java libraries as third party depedencies then all good. Now if you plan to dynamically link to Java libraries that require JVM opcodes without counterparts on DEX, SIMD, Panama, Java Standard Library post Java 11, then thought luck. See it as an opportunity to learn how to use the NDK (for SIMD), or write your own Kotlin versions.
- dbrgn 4y ago
  You're right, and I use Kotlin for all new projects. However, when working with legacy code and with teams that aren't familiar with Kotlin, introducing a newer Java version is much easier than introducing an entirely new language.
- pjmlp 4y ago
  Because regardless of Kotlin, modern Java libraries won't be usable on Android, despite the marketing how "compatible" Kotlin happens to be with Java.
grishka 4y ago
You can use Java 17 on Android, except features that require new classes and/or methods, obviously.
rr888 4y ago
Is there a path to upgrading Java on Android? Surely new Android releases could do easily?
- dbrgn 4y ago
  No, because Dalvik (https://en.wikipedia.org/wiki/Dalvik_(software) https://en.wikipedia.org/wiki/Dalvik_(software)) / ART (https://en.wikipedia.org/wiki/Android_Runtime https://en.wikipedia.org/wiki/Android_Runtime) are forks of Java. New features need to be re-implemented due to licensing issues. And Google seems to be focussed more on Kotlin than on newer Java features.
svieira 4y ago
sobs in j2objc AND sobs in GWT/J2CL

Nice new language features for Java users! sobs in Android-Java8

by dbrgn 4y ago

Nice new language features for Java users! sobs in Android-Java8

nine_k 4y ago

Android? Why not Kotlin then?

waynesonfire 4y ago
Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for.
- cies 4y ago
  > Kotlin was designed to replace Java 1.6 and that's about all it's good for. Not sure what K was designed for. But we use it to fix J's billion dollar "implicit nulls" mistake, and terse syntax (making it useful for templating: Kotlinx.html), and pass-as-value method references. We love it's hang towards immutability. K is not Haskell, but it sure feels a lot safer that J (where a lot of strings were used to refer to methods, and strings+Groovy was used to do templates). Bottom line: I'm too old --and life's too short-- for NPEs.
  - flatiron 4y ago
    Have your tried static analysis? When I used Java most (if not all) of our NPE problems were pointed out by sonar qube
    - ris58h 4y ago
      What if I don't want to put @Nullable/@NotNull all over the code?
      - seer-zig 4y ago
        Can't you setup your project to be `@NotNull` by default, and explicitly mark @Nullable fields? Those should be more rare anyway.
    - cies 4y ago
      Yes. But coupled with our Groovy templates (that we're now moving to Kotlinx.html) it did not really help much. This is not Java's problem per se (though one could argue that J's verbose syntax prohibits it for in-code HTML templating)
    - hn_throwaway_99 4y ago
      Ugh, to hear what hackarounds folks have to deal with in the Java ecosystem is kind of frightening. I moved from Java to Node (then Typescript) about 8 years ago. Moving to a language that doesn't allow implicit nulls makes a world of difference, importantly, at "programmer" time, not just build time. That is, when programming in VSCode, I immediately get feedback if I attempt to use a nullable variable in an unsafe manner. That has huge productivity benefits compared to if I only got that feedback after my build ran. Similarly, simple things like safe optional chaining (i.e. foo?.bar?.baz) makes code so much faster and easier to write, and AFAIK this hasn't been added to Java yet (correct me if I'm wrong).
nradov 4y ago
Kotlin is certainly a good general purpose language. But many developers would prefer to be able to use Java for Android development including the excellent tool chain and numerous libraries. It's a shame that commercial disputes between Google and Oracle have left us with this fragmented platform.
- Strum355 4y ago
  > the excellent toolchain and numerous libraries The same libraries that can be used from Kotlin?
  - pjmlp 4y ago
    Only if they can be usable from ART capabilities, and desugared into DEX opcodes.
- cies 4y ago
  > the excellent toolchain and numerous libraries The toolchain in both cases is basically IntelliJ (rebranded as Adroid Studio)
- pjmlp 4y ago
  Kotlin is still heavily dependent on Java ecosystem, so this excuse is nonsense, there is hardly any Kotlin without Java. See how sucessfull Kotlin/JS and Kotlin/Native are on the wild.
- Alupis 4y ago
  Give Kotlin an honest try. I think you will be impressed... and that's coming from a crusty old curmudgeon "get off my compiler" java fanboy.
tut-urut-utut 4y ago
Why learning a whole new language just because vendor refuses to upgrade? At that point one could also say "why Anrdoid?".
- wlpu 4y ago
  Because you can use the same toolchains, APIs, libraries, and even progressively migrate with both languages in the same project. Honestly, people who whine about Java 8 in Android and refuse to consider Kotlin are suffering by choice.
  - pjmlp 4y ago
    Only those that can be desuagared into Android Java, everything else will fail to either compile or map into ART features.
    - kuschku 4y ago
      All of Kotlin runs fine on Android, that's its point, that all of it can be desugared to run on a 1.6 or 1.8 JVM?
      - pjmlp 4y ago
        If you don't want to use modern Java libraries as third party depedencies then all good. Now if you plan to dynamically link to Java libraries that require JVM opcodes without counterparts on DEX, SIMD, Panama, Java Standard Library post Java 11, then thought luck. See it as an opportunity to learn how to use the NDK (for SIMD), or write your own Kotlin versions.
dbrgn 4y ago
You're right, and I use Kotlin for all new projects. However, when working with legacy code and with teams that aren't familiar with Kotlin, introducing a newer Java version is much easier than introducing an entirely new language.
pjmlp 4y ago
Because regardless of Kotlin, modern Java libraries won't be usable on Android, despite the marketing how "compatible" Kotlin happens to be with Java.

grishka 4y ago

You can use Java 17 on Android, except features that require new classes and/or methods, obviously.

rr888 4y ago

Is there a path to upgrading Java on Android? Surely new Android releases could do easily?

dbrgn 4y ago
No, because Dalvik (https://en.wikipedia.org/wiki/Dalvik_(software) https://en.wikipedia.org/wiki/Dalvik_(software)) / ART (https://en.wikipedia.org/wiki/Android_Runtime https://en.wikipedia.org/wiki/Android_Runtime) are forks of Java. New features need to be re-implemented due to licensing issues. And Google seems to be focussed more on Kotlin than on newer Java features.

svieira 4y ago

sobs in j2objc AND sobs in GWT/J2CL