Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Google: Kotlin soll erste…

Ich habe über ein Jahrzehnt in Java entwickelt...

  1. Thema

Neues Thema Ansicht wechseln


  1. Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: henry86 08.05.19 - 17:42

    und vor gut einem Jahr mit kotlin angefangen - und das im embedded Bereich, nicht auf Android.

    Inzwischen nutzen wir in der Firma in allen Bereichen kotlin und es ist für mich absolut nicht mehr vorstellbar, im Backend, embedded, Android oder Frontend (Javascript) Bereich irgendwas anderes zu nutzen.

    Klar, grundsätzlich können Umstände einen immer zwingen, aber wenn möglich, wird kotlin eingesetzt.

    Dass wir Code in verschiedensten Bereichen wiederverwenden können, dass sich mit kotlin eine ganze Menge boilerplate code erübrigt, Nullpointer exceptions Geschichte sind (!) und einige andere Vorteile mehr, macht es für mich zur derzeit besten Programmiersprache und ein zurück zu Java, c++, Javascript etc. sehr unwahrscheinlich (außer diese seltenen und schmerzhaften Ausnahmen, wo aufgrund bestimmter Randbedingungen das nicht anders möglich ist).

  2. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: deus-ex 08.05.19 - 18:24

    Ich kann das gleiche Swift sagen. Sehr modern und angenehm.

  3. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Pete Sabacker 08.05.19 - 19:07

    deus-ex schrieb:
    --------------------------------------------------------------------------------
    > Ich kann das gleiche Swift sagen. Sehr modern und angenehm.

    Ja. Swift und Kotlin sind super und ich würde mir wünschen, Kotlin könnte die Altlasten der Java-VM loswerden und vernünftige Generics implementieren.

  4. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: eisbart 08.05.19 - 21:19

    Hat nichts mit der jvm zu tun. Arrays sind zb im Gegensatz zu Java type safe.

    Kotlin will einfach möglichst kompatibel und einfach für Java devs sein und so lange gibt es das ding auch nicht. Vielleicht sehen wir ja irgendwann auch higher minded types, macros und type classes.

  5. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Scherzkasper 08.05.19 - 22:50

    Pete Sabacker schrieb:
    --------------------------------------------------------------------------------
    > Ja. Swift und Kotlin sind super und ich würde mir wünschen, Kotlin könnte
    > die Altlasten der Java-VM loswerden und vernünftige Generics
    > implementieren.

    Was ist denn an den Generics auszusetzen?

  6. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: hyperlord 08.05.19 - 23:07

    Die Generics in Java haben den großen Nachteil, dass die Typinformation zur Runtime nicht verfügbar ist. Kotlin bietet da immerhin reified an, aber das geht halt auch nicht immer.

  7. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Proctrap 09.05.19 - 01:59

    geht mir so mit Rust aber bis ich den bestehenden Android Code auf kotlin portiert hab wirds noch brauchen..

    ausgeloggt kein JS für golem = keine Seitenhüpfer

  8. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Pete Sabacker 09.05.19 - 06:56

    Proctrap schrieb:
    --------------------------------------------------------------------------------
    > geht mir so mit Rust aber bis ich den bestehenden Android Code auf kotlin
    > portiert hab wirds noch brauchen..

    Strg+Alt+Shit+K!

  9. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: DerET 09.05.19 - 08:34

    > Strg+Alt+Shit+K!
    Ich nehme ein F und möchte lösen!

  10. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Scherzkasper 09.05.19 - 09:32

    hyperlord schrieb:
    --------------------------------------------------------------------------------
    > Die Generics in Java haben den großen Nachteil, dass die Typinformation zur
    > Runtime nicht verfügbar ist. Kotlin bietet da immerhin reified an, aber das
    > geht halt auch nicht immer.

    Eigentlich finde ich das gar nicht schlecht. Wenn die Funktion ein Typenobjekt braucht, dann muss man das explizit übergeben, in den meisten Fällen wird dann dadurch der generische Typ der Funktion vom Compiler impliziert. Zumindest finde ich die Signatur dadurch verständlicher. Ich finde auch, dass es irgendwie hacky aussieht, aber eigentlich ist damit alles typsicher und wie gesagt expliziter.

  11. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: tomate.salat.inc 09.05.19 - 09:39

    Aber unnötig. Schau dir mal C# an - da hast du richtige Generics (und nicht wie bei Java wo alles einfach hinter Object ist).

    Dementsprechend kannst du auch anhand der Generics neue Objekte erstellen: https://docs.microsoft.com/de-de/dotnet/csharp/language-reference/keywords/new-constraint

  12. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Das Osterschnabeltier 09.05.19 - 11:24

    tomate.salat.inc schrieb:
    --------------------------------------------------------------------------------
    > Aber unnötig. Schau dir mal C# an - da hast du richtige Generics (und nicht
    > wie bei Java wo alles einfach hinter Object ist).
    >
    > Dementsprechend kannst du auch anhand der Generics neue Objekte erstellen:
    > docs.microsoft.com

    Ein "new T()" nicht zu erlauben ist eine Design Entscheidung und hat per-se nichts mit reified generics zu tun. Siehe auch: https://www.javaworld.com/article/2074987/why-new-t---is-not-possible-in-java.html

    Möglichkeiten zur Implementierung in die Sprache gäbe es genug, es ist halt blöd wenn die Klasse wo dur brauchst keinen Standardkonstruktor bietet. Ist aber auch in Java nicht wirklich schlimm, weil man einfach einen Supplier<T> übergeben kann (je nach Use-Case ist es praktisch das schon im Konstruktor und nicht erst auf Methodenebene).

    Dadurch gewinnt man, dass man sowohl Konstruktoren als auch Factories für die Instanzierung verwenden kann, besser gehts eigentlich nicht.

  13. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Scherzkasper 09.05.19 - 12:12

    Genau, ich nutze in Kotlin einfach immer funktionale Typen, da kann man jede Methode rein reichen, deren Signatur passt, auch den Konstruktor.

    Das ist dann im Gegensatz zu T() auch typsicher



    1 mal bearbeitet, zuletzt am 09.05.19 12:13 durch Scherzkasper.

  14. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Pete Sabacker 09.05.19 - 12:17

    Das Osterschnabeltier schrieb:
    --------------------------------------------------------------------------------
    > Ein "new T()" nicht zu erlauben ist eine Design Entscheidung und hat per-se
    > nichts mit reified generics zu tun. Siehe auch: www.javaworld.com

    Sicher? Die 'beschissenen' Generics (manche mögen das ja irgendwie ..) aus Java sind doch mehr mit der Abwärtskompatibilität begründet.

  15. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: foobarJim 09.05.19 - 14:20

    Das Osterschnabeltier schrieb:
    --------------------------------------------------------------------------------
    > Ein "new T()" nicht zu erlauben ist eine Design Entscheidung und hat per-se
    > nichts mit reified generics zu tun. Siehe auch: www.javaworld.com
    >
    > Möglichkeiten zur Implementierung in die Sprache gäbe es genug, es ist halt
    > blöd wenn die Klasse wo dur brauchst keinen Standardkonstruktor bietet. Ist
    > aber auch in Java nicht wirklich schlimm, weil man einfach einen Supplier
    > übergeben kann (je nach Use-Case ist es praktisch das schon im Konstruktor
    > und nicht erst auf Methodenebene).
    >
    > Dadurch gewinnt man, dass man sowohl Konstruktoren als auch Factories für
    > die Instanzierung verwenden kann, besser gehts eigentlich nicht.

    Dass das Erzeugen von Objekte anhand der Typinformation nicht gewünscht ist, kann ich anhand deines Links nachvollziehen. Es gibt aber andere Beispiele, in denen es durchaus praktisch wäre, wenn der Typ zur Laufzeit vorhanden wäre. In Scala kann man z.B. durch Pattern Matching auf Typen matchen. Unter Umständen funktioniert das aber nicht, weil der Typ nicht mehr greifbar ist. Ich hatte schon einige Fälle, in denen mich das Type-Erasure ziemlich genervt hat. Ich würde es jetzt nicht unbedingt als Feature von Java beschreiben.

  16. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: eisbart 09.05.19 - 14:45

    Type erasure gibt es auch in anderen sprachen (zB Rust) aus performance gründen. Es steht auch jedem Compiler frei für jede Instanz code mit dem konkreten Typ code zu generieren (wie in Rust) bzw Objekte mit mehr meta Informationen zu versehen (zB über annotations)

    Der jetzige status ist einfach eine Abwägung von vor- und Nachteilen und ist vollkommen in Ordnung. C# erlaubt halt metaprogramming ein bisschen besser dafür verwendet Java weniger RAM (nicht lachen ;)

  17. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Das Osterschnabeltier 09.05.19 - 20:03

    foobarJim schrieb:
    --------------------------------------------------------------------------------
    > Das Osterschnabeltier schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ein "new T()" nicht zu erlauben ist eine Design Entscheidung und hat
    > per-se
    > > nichts mit reified generics zu tun. Siehe auch: www.javaworld.com
    > >
    > > Möglichkeiten zur Implementierung in die Sprache gäbe es genug, es ist
    > halt
    > > blöd wenn die Klasse wo dur brauchst keinen Standardkonstruktor bietet.
    > Ist
    > > aber auch in Java nicht wirklich schlimm, weil man einfach einen
    > Supplier
    > > übergeben kann (je nach Use-Case ist es praktisch das schon im
    > Konstruktor
    > > und nicht erst auf Methodenebene).
    > >
    > > Dadurch gewinnt man, dass man sowohl Konstruktoren als auch Factories
    > für
    > > die Instanzierung verwenden kann, besser gehts eigentlich nicht.
    >
    > Dass das Erzeugen von Objekte anhand der Typinformation nicht gewünscht
    > ist, kann ich anhand deines Links nachvollziehen. Es gibt aber andere
    > Beispiele, in denen es durchaus praktisch wäre, wenn der Typ zur Laufzeit
    > vorhanden wäre. In Scala kann man z.B. durch Pattern Matching auf Typen
    > matchen. Unter Umständen funktioniert das aber nicht, weil der Typ nicht
    > mehr greifbar ist. Ich hatte schon einige Fälle, in denen mich das
    > Type-Erasure ziemlich genervt hat. Ich würde es jetzt nicht unbedingt als
    > Feature von Java beschreiben.

    Ja, ein Feature ist es nicht und Rückwärtskompatibilität war auch der Grund für Erasure (kann aber sein dass sich das im Zuge von Projekt Valhalla ändert).

    Einfach nur aus Neugier: Was für Use-Cases sind das?
    Ich bin kein Vollzeit Java Entwickler und hatte mit Generics noch nie nennenswerte Probleme wo durch Erasure entständen wäre.

  18. Re: Ich habe über ein Jahrzehnt in Java entwickelt...

    Autor: Pete Sabacker 10.05.19 - 10:54

    Das Osterschnabeltier schrieb:
    --------------------------------------------------------------------------------
    > Ja, ein Feature ist es nicht und Rückwärtskompatibilität war auch der Grund
    > für Erasure (kann aber sein dass sich das im Zuge von Projekt Valhalla
    > ändert).

    > Einfach nur aus Neugier: Was für Use-Cases sind das?
    > Ich bin kein Vollzeit Java Entwickler und hatte mit Generics noch nie
    > nennenswerte Probleme wo durch Erasure entständen wäre.

    Hatte mal das Problem, dass Java bei JSON-Deserialisierung in einer BigDecimal-Variable einen BigInteger-Wert abspeicherte. Das war ein Fall, bei dem ich mit Erasure richtig auf die Fresse geflogen bin. Ansonsten sehe ich Erasure - wie Java es tut - aber eher als Nachteil an. Typinformationen müssen regelmäßig bereits im Konstruktor übergeben werden, das Ganze wird nur noch geschwätziger, als Java es ohnehin schon ist. Und von Constraints brauchen wir gar nicht erst zu reden, da werden die Klassensignaturen ganz schnell mal völlig bizarre Konstrukte.

    Einziger Vorteil aus meiner Perspektive: Klassen wie "AnySomething", wie man sie aus Swift kennt, sind nicht nötig, sondern durch die Wildcard quasi implizit gegeben.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hirschvogel Holding GmbH, Denklingen
  2. TeamBank AG, Nürnberg
  3. d.velop Life Sciences GmbH, Gescher
  4. ERGO Group AG, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 1,24€
  2. 2,99€
  3. (-20%) 23,99€
  4. 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Doom Eternal angespielt: Die nächste Ballerorgie von id macht uns fix und fertig
Doom Eternal angespielt
Die nächste Ballerorgie von id macht uns fix und fertig

E3 2019 Extrem schnelle Action plus taktische Entscheidungen, dazu geniale Grafik und eine düstere Atmosphäre: Doom Eternal hat gegenüber dem erstklassigen Vorgänger zumindest beim Anspielen noch deutlich zugelegt.

  1. Sigil John Romero setzt Doom fort

Wolfenstein Youngblood angespielt: Warum wurden diese dämlichen Mädchen nicht aufgehalten!?
Wolfenstein Youngblood angespielt
"Warum wurden diese dämlichen Mädchen nicht aufgehalten!?"

E3 2019 Der erste Kill ist der schwerste: In Wolfenstein Youngblood kämpfen die beiden Töchter von B.J. Blazkowicz gegen Nazis. Golem.de hat sich mit Jess und Soph durch einen Zeppelin über dem belagerten Paris gekämpft.
Von Peter Steinlechner


    Elektromobilität: Wohin mit den vielen Akkus?
    Elektromobilität
    Wohin mit den vielen Akkus?

    Akkus sind die wichtigste Komponente von Elektroautos. Doch auch, wenn sie für die Autos nicht mehr geeignet sind, sind sie kein Fall für den Schredder. Hersteller wie Audi testen Möglichkeiten, sie weiterzuverwenden.
    Ein Bericht von Dirk Kunde

    1. Proterra Elektrobushersteller vermietet Akkus zur Absatzförderung
    2. Batterieherstellung Kampf um die Zelle
    3. US CPSC HP muss in den USA nochmals fast 80.000 Akkus zurückrufen

    1. TNEP 1.0: NFC-Protokoll für das Steuern von IoT-Geräten kommt
      TNEP 1.0
      NFC-Protokoll für das Steuern von IoT-Geräten kommt

      Der NFC-Standard wird erweitert. Eine neue Spezifikation ermöglicht das direkte Steuern von Geräten. Basis ist die NDEF-Kommunikation, mit der bereits Tags beschrieben werden können. TNEP geht einen Schritt weiter.

    2. Libra: Facebook verrät Details zu seiner Kryptowährung
      Libra
      Facebook verrät Details zu seiner Kryptowährung

      Nun ist es offiziell: Gemeinsam mit 27 Unternehmen möchte Facebook die Kryptowährung Libra veröffentlichen. Diese soll 2020 kommen und mit einigen Besonderheiten aufwarten.

    3. Windows 10: Docker Desktop nutzt künftig WSL 2
      Windows 10
      Docker Desktop nutzt künftig WSL 2

      Das neue Windows Subsystem für Linux nutzt eine ähnliche Architektur, wie sie Docker bisher selbst gebaut hat - nur eben nativ. Das Docker-Team wechselt für den Windows-Support deshalb auf das WSL 2 und verspricht eine nahtlose Integration.


    1. 14:52

    2. 13:50

    3. 13:10

    4. 12:25

    5. 12:07

    6. 11:52

    7. 11:43

    8. 11:32