Warum hat Java dieses und jenes nicht...

[Mart]

Ich habe halt ein paar "rundumschläge" gemacht zu andere sprachen und da gibts fancy sachen die halt "Fehlen" in java bzw ich nicht so gefunden habe und versteh nicht wieso es sowas nicht in java gibt

1. Basierend auf https://blog.allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html den 1sten Punkt hat Kotlin =>

Well, in Kotlin, method arguments are values, so you can’t change the num argument. That’s good language design because you shouldn’t change method arguments.

wieso ist es dann nicht standardmäßig so in java dass man alle Argumente als Final deklariert
weil es ist öfter der Fall dass man die Argumente Final braucht bzw benutzen sollte
2. super Aufruf von C#
wenn man das hat als Konstruktor hat in C#

public xyz ( argumente ) : base ( argumente )

dann könnte man es doch in java so umsetzen wenn man einen Super Konstruktor will

public xyz ( String id ) super ( id ) {

}

oder so ähnlich ... ich bin sowieso dazu gezwungen den super aufruf in der Ersten Zeile zu machen dh die Restriktion gibts ja schon
es würde halt so besser ins Auge fallen wenn man super aufrufen will wenn man einen anderen konstruktor aufrufen will kann man es ja auch irgendwie so umsetzen

public xyz ( String id ) this ( id ) {

}

es würde halt die lesbarkeit erhöhen, von der Funktionalität ändert sich nichts da diese Methoden sowieso an erster stelle stehen MÜSSEN
3. c# Getter und Setter
in c# kann ich getter und setter genauso shcreiben wie in java => sollte auch in java bleiben

in c# kann ich aber zb public int xy = 0; { get ; set }

syntax weis ich gerade nicht genau
mit dem Lombok auto erzeuger für getter und setter "gibts das" merh oder weniger, aber warum ist sowas nicht standardmäßig in java? sondern brauche eine Externe Bibliothek




Allgemein ist gefühlt java von den "fancy" sachen hinterher wie jetzt bei den 3 Themen oben beschrieben
ich bin aber selber gegen "ultra fancy" wie zb in python da hat man 1e zeile die ein Neuronales netzwerk aufbaut und man hat keine ahnung was passiert
oder wie in dem Obigen link
[CODE lang="java" title="java code => ohne zu wissen was die Klasse tut versteh ich es halbwegs"]public int parseAndInc(String number) {
return Optional.ofNullable(number)
.map(Integer:arseInt)
.map(it -> it + 1)
.orElse(0);
}
[/CODE]
[CODE lang="java" title="Kotlin => keine ahnung was da passiert es ist zu zu kurz"]fun parseAndInc(number: String?): Int {
return number.let { Integer.parseInt(it) }
.let { it -> it + 1 } ?: 0
}
[/CODE]
vllt sind das alles auch nur meine eindrücke von java? andere sprachen wie Kotlin Python usw gehen halt davon aus dass der der es programmiert die ganzen fancy sachen weiß aber manchmal ist super fancy gar nicht mal so toll

 

[kneitzel]

Also Sprachen sind halt unterschiedlich und da ist es ganz normal, das es nicht Alles überall gibt.

Die Frage ist auch immer: braucht man etwas wirklich? Vieles, das als Feature gut aussehen könnte stellt sich dann als weniger gut heraus.

Was man gut erkennen kann: Sprachen entwickeln sich weiter. Wenn man eine kleine Auswahl an Sprachen betrachtet, dann hat man z.B.
- Java. Da wurde dann damals einiges genommen, was sinnvoll schien. Der "Managed" Ansatz mit Bytecode, VM, GC, ... ist da vor allem zu nennen.
- C# Das kam deutlich später. Hier konnte man sich die besten Elemente von dem, was es so gab, anschauen. Das führte zu einigen Vorteilen, die ich z.B. bei Java immer noch vermisse.
- Kotlin kam dann auch noch - hier wurde dann auch versucht, einiges besser zu machen. Die spezielle Behandlung von null ist hier z.B. auffällig.
- Dart - das wäre so die aktuellste Sprache, die ich mir angesehen habe. Dort werden auch viele, interessante Wege gegangen, die einiges deutlich vereinfachen. Kein public/protected/private mehr. Alles ist public, es sei denn, es startet mit einem _. Dann die Trennung Interface / Klasse ist hinfällig. Du kannst so ableiten, wie Du willst: Klasse ableiten, Interface der Klasse übernehmen oder ganz ohne Ableitung den Inhalt übernehmen. Den Ansatz finde ich sehr interessant.

Was die konkreten Punkte angeht:
1. Ob nun ein Parameter final ist oder nicht: Es ist und bleibt ein call by value. Generell kann man alle Parameter final machen (ich neige z.B. dazu und meine default Konfiguration meckert ein fehlendes final an). In dem Punkt sehe ich also kein wirkliches Problem.

2. Ob der Aufruf noch direkt im Methodenkopf ist oder als erste Zeile: Da sehe ich erst einmal keinen wirklichen Unterschied.

3. Hier musst Du aufpassen! In .Net ist das Beschriebene eben kein "Getter" / "Setter" wie in Java sondern eine Property. Das ist streng genommen nicht ganz das Gleiche. Java ist hier deutlich konsequenter, denn es wird eben kein Feld nach außen gegeben sondern eine Methode. Da gibt es so ein "Mischmasch" nicht. Die Frage ist: braucht man dies so in der Form? In der Praxis hat sich das durchaus bewährt fand ich. Da bin ich also ganz bei Dir. Ich war in Java auch lange Verfechter von Lombok, wobei ich dann aus rein praktischen Gründen zum generieren von Code übergegangen bin. (Ich meine, es gab Probleme mit JavaDoc und bei neuen Versionen von IntelliJ fehlte erst das Plugin. JetBrains hat das Plugin dann aber wohl mit integriert, so dass diese Problematik weg ist.)

Java hinkte bei der Entwicklung aus meiner Sicht lange hinterher. Neue Features kamen nicht oder viel zu langsam. Hier ist man aus meiner Sicht zu Konservativ. Und dann an (falschem) festhalten - ich bin schon mehrfach über Dinge im Framework gestolpert wo ich mich frage: Was haben die Entwickler geraucht? Und wenn man recherchiert, dann findet man die Geschichte dahinter und das einfache Fazit: "Ja, ist scheiße. Aber wir lassen es som, weil es halt so ist und wir da keine Veränderung mehr wollen.". Ja, Breaking Changes ist doof. Aber diese sind durchaus wichtig, wenn etwas sauber und konsistent sein soll. Und wenn dann eine Software auf genau dem scheiß Verhalten aufbaut, dann muss diese Anwendung beim Wechsel der Java Version angepasst werden. Aber das ist nur meine Sicht. Das Vermeiden von Breaking Changes ist halt auch durchaus verständlich aber das sehe ich halt nicht so stark. Url als Klasse hatten wir neulich in einem Thread um ein Beispiel zu nennen.

Generell ist die Entwicklung von neuen Sprachen immer sehr interessant und es lohnt sich, da ein Blick drauf zu werfen. Man findet dann viele Strömungen, die alle durchaus wichtig und interessant sind. Die Funktionale Entwicklung war ein großer Punkt, der gekommen ist. Async Calls ein anderer (Da fand ich den Ansatz von .Net übrigens deutlich besser - da wurde die ganze Klassenbibliothek diesbezüglich umgestellt. Eine Methode Xyz hat dann noch XyzAsync als Erweiterung bekommen). Aber da gibt es ja einiges, was man auch in der Java Welt findet: AOP wäre da noch ein Stichwort. So kann man noch sehr viel benennen. Und man muss schauen, was da so für Entwicklungen kommen und gehen ...

Ggf. geht es dann auch wieder weg von OOP. Ansätze sieht man bei ein paar Sprachen.

Aber auch bei anderen Themen ist da sehr viel im Wandel. Datenbanken - da geht es ja mehr und mehr weg von Relationalen Datenbanken. Neue Konzepte kommen zumindest rein. Clean Code ist auch ständig im Wandel - hatte vor einigen Wochen einen Beitrag gelesen, der sich gegen SOLID aussprach - leider gab es bisher keinen Folgeartikel, der mögliche Alternativen aufzeigte (oder ich habe ihn schlicht verpasst)....

Die Software Entwicklung ist noch jung und dementsprechend ist da auch noch sehr viel Bewegung in diesem Fachbereich. Wenn ich auf die letzten 30 Jahre zurück blicke, dann war es immer sehr interessant und ich bin sicher, dass die nächsten 30 Jahre nicht langweiliger werden

Edit: Bei der Kritik an der Java Weiterentwicklung habe ich vergessen zu schreiben: Da hat sich aus meiner Sicht einiges getan. Die Entwicklung scheint etwas mehr Fahrt aufgenommen zu haben und es gab schon viele gute Anpassungen. Java 8 war ein super Update aber auch danach war die Entwicklung aus meiner Sicht durchaus positiv. Module mit Jlink / JPackage oder als Alternative GraalVM. Records und co ... Die Entwicklung mit den JSRs verläuft positiv und auch den Wechsel von Java EE zu Jakarta EE sehe ich positiv für die weitere Entwicklung.

 

[Mart]

Was die konkreten Punkte angeht:
1. Ob nun ein Parameter final ist oder nicht: Es ist und bleibt ein call by value. Generell kann man alle Parameter final machen (ich neige z.B. dazu und meine default Konfiguration meckert ein fehlendes final an). In dem Punkt sehe ich also kein wirkliches Problem.

es sind halt zeichen die ich extra schreiben muss, würde es standardmäßig final sein dann könnte man sich das sparen + man hat "qualitativ" hochwertigeren code .. wo man bei java sagen kann dass da schon eine Priorität liegt

2. Ob der Aufruf noch direkt im Methodenkopf ist oder als erste Zeile: Da sehe ich erst einmal keinen wirklichen Unterschied.

ich finde es Übersichtlicher, somit würde man nicht in die " versuchung " kommen es an die Zweite Stelle zu setzen sondern es wird automatisch an erste stelle gesetzt und man sieht es eifnacher es ist ja doch ein "spezieller" methoden aufruf

Java 8 war ein super Update aber auch danach war die Entwicklung aus meiner Sicht durchaus positiv. Module mit Jlink / JPackage oder als Alternative GraalVM. Records und co ... Die Entwicklung mit den JSRs verläuft positiv und auch den Wechsel von Java EE zu Jakarta EE sehe ich positiv für die weitere Entwicklung.

ja es hat sich viel getan wie das instanceof wo man automatisch dann eine Referenz hat xyz instanceof Button x zb...
es gibt da schon "fancy" sachen die das Programmieren einfacher machen, bei den anderen sachen würde man sich halt denken dass man es mal in erwägung ziehen könnte


was halt auch möglich wäre eine Java hau drauf methode durchzuführen vllt sogar härter als in java8 dass man alles was vorher liegt zur "rückwärts kompatibilität" klein häckselt um die Alt last weg zu kriegen die alles nur verkomplizieren

es gibt viele fancy sachen die man klauen kann von anderen sprachen , c# hat das auch getan von java warum nicht einfahc mal den spieß umdrehen

 

[Neumi5694]

Ich find's eigentlich ganz angenehm, dass die Argumente eben NICHT final sind. Der Schreiberling, der sich über Kotlin geäußert hat, ist wohl anderer Meinung.
Wenn du erst mal den Super-Konstruktor mit dem Ergebnis einer Funktion als Argument aufrufst, ist es mit der Übersichtlichkeit in der gezeigten Schreibweise sehr schnell vorbei.

Alles genannte sind keine Must-Haves. Der eine mag sie übersichtlicher/angenehmer finden, der andere nicht.

Fast jede Frage nach einem "Wieso" lässt sich beantworten mit: "Zu dem Zeitpunkt schien es eine gute Idee zu sein".


Wenn du nach dem "wieso" fragen willst, frage lieber, warum Klassen wie Point oder GridbagConstraint direkten Zugriff auf ihre Variablen erlauben.
Jedem Hobbyprogrammierer wird gesagt, das auf keinen Fall zu tun. Aber die JDK hat das so im Standard drin.

 

[M.L.]

Generell ist es wohl auch auf jeder Ebene (privat/wirtschaftlich...) langfristig ärgerlich wenn in kurzen (unplanbaren) Zeitabständen irgendwelche Änderungen vorgenommen werden müssen, weil es "fancy" ist (Stichwort auch Investitionssicherheit)

 

[LimDul]

Manche Dinge sind einfach Geschmacksache / syntaktischer Zucker. Da fällt für mich z.B. die Konstruktor Schreibweise dazu.

was halt auch möglich wäre eine Java hau drauf methode durchzuführen vllt sogar härter als in java8 dass man alles was vorher liegt zur "rückwärts kompatibilität" klein häckselt um die Alt last weg zu kriegen die alles nur verkomplizieren

Nein, das wäre nicht möglich. Es ist extrem wichtig, dass die Änderungen möglichst abwärtskompatibel sind. Das heißt:

Code, der mit einer älteren Java-Version kompiliert wurde, muss auch als Abhängigkeit mit einem Programm mit neuerer Java-Version laufen. Das ist eine Muss-Anforderung, an der kann man kaum rütteln.

Code, der für eine ältere Java-Version geschrieben wurde, sollte sich möglichst ohne Änderungen in einer neueren Java-Version kompilieren lassen. Das ist etwas weicher, aber der Anpassungsbedarf muss gering sein.

Java ist in der Enterprise Welt beheimatet, dass heißt die Programme haben hier Laufzeiten >10 Jahre und man will an viele Stellen der Programme nicht mehr ran. Dementsprechend sind breaking Changes extrem kritisch und müssen mehr als "Fancy & Cool" sein.

 

[Robert Zenz]

wieso ist es dann nicht standardmäßig so in java dass man alle Argumente als Final deklariert

Mein persoenliches Verhalten ist dass ich Argumente in 99.99% der Faelle als final betrachte, aber es nicht dazu schreibe, weil das einfach zu viel Rauschen ist.

Sie final standardmaeszig zu machen, weisz ich nicht, es sind halt auch nur Variablen Deklarationen, und jeder geht damit eben anders um. Manchmal ueberschreibe auch ich sie mit "trivialen" Aenderungen, zum Beispiel stringParameter = stringParameter.intern(), aber das ist sehr selten.

super Aufruf von C#
... es würde halt die lesbarkeit erhöhen, von der Funktionalität ändert sich nichts da diese Methoden sowieso an erster stelle stehen MÜSSEN

Was erhoeht denn daran die Lesbarkeit?

public MySuperClass(int paramValueA, int paramValueB, int paramValueC, int paramValueD) {
    super(paramValueA, paramValueB, paramValueC, paramValueD);
}

public MySuperClass(int paramValueA, int paramValueB, int paramValueC, paramValueD) super (paramValueA, paramValueB, paramValueC, paramValueD) {
}

Das spielt doch echt keine Rolle, das ist eine solche Mikro-Optimierung ueber die man im Internet masturbieren kann, aber die genau Null Einschlag in der realen Welt hat.

c# Getter und Setter

Grundsaetzlich bin ich der Meinung dass eine Programmiersprache so simpel und einheitlich sein sollte wie moeglich. Wieviele Wege gibt es in C# Properties zu deklarieren? Ich glaub drei in der Zwischenzeit, vielleicht sogar vier, in Java genau eine und das ist kein Sonderfall sondern einfach Methoden. Finde ich besser. Also das deklarieren von Gettern und Settern war in meiner Arbeit noch nie ein Flaschenhals und ich habe mir noch nie gewuenscht "meine Guete, wenn das nur eine Zeile waere, dann haette ich jetzt im ganzen Projekt 100 Zeilen gespart, das waere der Wahnsinn".

Allgemein ist gefühlt java von den "fancy" sachen hinterher wie jetzt bei den 3 Themen oben beschrieben

Je mehr "fancy" Sachen eine Sprache hat, umso schwerer wird man sich in den bestehenden Code einarbeiten, Perl ist hier ein wunderschoenes Beispiel. Super Sprache, tolle Funktionalitaet, keine Frage, aber so viele Moeglichkeiten Dinge zu machen, in verschiedenen Formen und vor allem in "kurzen" Formen, dass eine bestehende Code-Basis eine extreme Lernkurve haben kann.

Ich muss hier aber auch ehrlich sein und sagen ich bin hier ein alter Mann und ich haette gerne dass ihr euch alle von meinem Rasen verzieht, aber je weniger Sonderfaelle in einer Programmiersprache sind, um so besser meiner Meinung nach, weil umso weniger muss man denken, umso schneller kommt man in eine Code-Basis und ein Projekt hinein, umso weniger sieht dass Projekt am Ende aus wie Kraut und Rueben. Weil sehen wir's ein, ein Projekt das 20 Jahre lebt, wird am Ende genug Programmierer gehabt haben die ihr eigenes Ding machen, und da hilft eine Programmiersprache mit vielen Moeglichkeiten nicht das wartbar zu halten.

 

[White_Fox]

Je mehr "fancy" Sachen eine Sprache hat, umso schwerer wird man sich in den bestehenden Code einarbeiten, Perl ist hier ein wunderschoenes Beispiel.

C++ ist ein schönes Beispiel. Wird seit – Wie lange? 30 Jahre? 40 Jahre? – mit dem jeweils aktuellsten Scheiß vollgestopft, und heute kommst du in die Sprache einfach nicht mehr rein. Es gibt eingefleischte C++-Benutzer, die behaupten, daß die Sprachversionen ab irgendeinem Versionsstand eigentlich nix mehr miteinander zu tun haben und die neueren Versionen eigentlich als eigenständige Sprache betrachtet werden müßten. Diese Leute, von denen ich das habe, hielten das aber fälschlicherweise auch noch für einen Vorteil.

Java hatte da von anfang an andere Designprinzipien. Einfachheit war eines davon.

 

[Mart]

Java hatte da von anfang an andere Designprinzipien. Einfachheit war eines davon.

ja

die schwierigkeit in java entsteht meiner meinung nach durch libs die ich hole, wenn ich ka... den guice injector nicht versteh kann ich ihn immer noch raus schmeißen aus meiner maven dependency datei


wir haben dieses semester c++ und das gefühl ist schon da dass irgendwas im nachhinein als gadget eingefügt wurde... zb c++ klassen zu programieren macht nicht wirklich spaß aber das wird wahrscheinllich noch etwas von den einfachen dingen sein