Przewaga Javy nad Kotlinem

Polecam wpis od allegro
https://allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html

Wszystko ma swoje plusy i minusy, na korzysc Javy na pewno przemawia ilość tutoriali, rozwiązanych problemów.

Kotlin to jest Java++
Dowolny kod w Javie można przerobić na Kave albo Jotlina jakiegoś, więc nie ma za bardzo żadnych "ograniczeń". W drugą stronę trudniej ;]
Java to jest taki trochę niskopoziomowy (w porównaniu do Kotlina, Scali czy Clojure) język referencyjny dla JVM.

Piszemy ostatnie kilka miesięcy w Kotlinie, ale jakoś nie zauważyłem efektu "wow". Klepie się podobnie jak w Javie i raczej dość naturalnie. Trochę więcej syntactic sugars, trochę mniej boilerplate code, ale nie widzę jakiejś drastycznej różnicy w kodzie.

Na korzyść Javy przemawia: tony programistów, ktrórzy umieją napisać BookStore w Javie / Springu.

Dowolny kod w Javie da się przetłumaczyć na kod w Kotlinie praktycznie 1:1. Trudności są w miejscach gdzie Java przejechała się na własnych ułomnościach i coś trzeba było z tym zrobić:

• generyki w Kotlinie działają inaczej niż w Javie
• brak statycznych elementów klasy
  Założeniem Kotlina jest, że każdej klasy Java da się użyć z marszu w Kotlinie i odwrotnie więc kod napisany w Kotlinie da się przetłumaczyć na kod napisany w Javie, ale czasami trzeba jednak coś przepisać inaczej, bo np. Kotlin ma własne kolekcje i strumienie.

Istotną wadą Kotlina może być za to brak tak rozbudowanej listy kolekcji w związku z czym podczas rekrutacji bez sensu jest pytać "czym się różni LinkedList od ArrayList" i pozostaje jedynie pytanie o różnice pomiędzy klasą abstrakcyjną a interfejsem, ale to akurat istotne jest jedynie dla seniorów.

Kotlin ma własne kolekcje i strumienie.
Istotną wadą Kotlina może być za to brak tak rozbudowanej listy kolekcji w związku z czym podczas rekrutacji bez sensu jest pytać "czym się różni LinkedList od ArrayList" i pozostaje jedynie pytanie o różnice pomiędzy klasą abstrakcyjną a interfejsem, ale to akurat istotne jest jedynie dla seniorów.

Kotlin rozszerza standardowe kolekcje z Javy. To Scala ma własne niekompatybilne z Javą kolekcje i trzeba używać wrapperów, by móc np przenieść Scalową Listę do metody oczekującej Javowej Listy.

Przykłady kolekcji w Kotlinie:

• https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-array-list/index.html
  typealias ArrayList<E> = ArrayList<E> - ArrayLista z Kotlina jest aliasem na ArrayListę z Javy
• https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-linked-hash-map/index.html
  typealias LinkedHashMap<K, V> = LinkedHashMap<K, V> - LinkedHashMap z Kotlina jest aliasem na LinkedHashMap z Javy
• https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-hash-map/index.html
  typealias HashMap<K, V> = HashMap<K, V> - HashMap z Kotlina jest aliasem na HashMap z Javy
• i tak dalej

Możesz sobie spokojnie użyć także innych kolekcji z Javy w Kotlinie, bez wrapperów i bez konwersji. Na przykład:

fun main(args: Array<String>) {
    val kolekcja: MutableList<String> = java.util.LinkedList<String>()
    kolekcja.add("Hello")
    kolekcja.add("World")
    println(kolekcja)
}

https://www.ideone.com/NgVvXY

generyki w Kotlinie działają inaczej niż w Javie

Różnica sprowadza się głównie do use-site variance vs declaration-site variance: https://stackoverflow.com/q/4231305 Declaration-site variance jest między innymi w: C#, Kotlinie, Scali. Nie w Javie.

Niektórzy myślą, że Kotlin rozwiązuje problem wymazywania typów poprzez słówko kluczowe reified pokazane tutaj: https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters
Prawda jest taka, że Kotlin wcale magicznie nie odzyskuje wymazanych typów. Po prostu słówko kluczowe reified wymaga także słówka kluczowego inline, a więc ciało metody jest wklejone w miejsce wywołania na etapie kompilacji i także na etapie kompilacji kompilator statycznie oblicza którą klasę tworzymy. To jest coś zupełnie innego niż w C#, aczkolwiek samo podniecenie w związku z kompilującym się kodem typu new T() (w metodzie generycznej) jest takie samo.