Interessantes über var in Java 10

http://benjiweber.co.uk/blog/2018/03/03/representing-the-impractical-and-impossible-with-jdk-10-var/

Leider kein val oder let. Das heißt dann immer noch final var. Und nur als lokale Variablen nutzbar.
Ein wirklich sehr seichter Einstieg in diesen Bereich. Schade.

Finde ich auch dumm. Wenn es Scala, Kotlin und JS schon sehr erfolgreich mit unveränderlicher Variante vormachen, hätte man es wirklich auch gleich übernehmen können.

val fände ich auch nett aber aber gut es gibt eh implicit final also nicht ganz so tragisch.

und die Entscheidung, dass es nur für lokale Variablen gilt, finde ich nicht so schlecht.
Gerade in scala finde ich es eher schade, dass es nicht vom Compiler verlangt wird public Methods mit einem Rückgabetyp zuversehen.

Naja, Scala, Kotlin und Co sind deshalb erfolgreich, weil der Boilerplate Code stark zurück geht. Warum es in Java immer noch keine Properties gibt, entzieht sich mit total (und komm mir bitte nicht mit Lombok :))

Naja, die Variable nicht bewusst ändern und vom Compiler zugesichert bekommen, dass man sie nicht ändert, ist schon ein Unterschied :wink:

Ich hätte mir ja die final Variante als Standard gewünscht, wenn man nur eins einführt. Das man allerdings zugunsten des einfacheren Sprachumfangs darauf verzichtet hat, ist zumindest teilweise verständlich…

Mit denen bin ich noch nie so wirklich warm geworden :sweat_smile: Den Lombok-Weg finde ich da angenehmer (zumindest die Lösung mit Annotations, nicht die interne Umsetzung, dafür wäre eine “offizielle” API ganz interessant)

Lombok ist doch eigentlich nur eine Krücke, weil Java diese Sprachfeatures nicht mitbringt, oder? Und warum Annotationen, wenn es auch direkt gehen würde?

Joa, Lombok macht allerdings auch noch mehr als nur “properties”

Naja, das wäre ein neues Sprach-Feature vs. Nutzung eines vorhandenen und weit verbreiteten.

Das Properties nach außen wie normale Felder nutzbar sind, finde ich eher unschön, einfache Getter/Setter (gerne auch “fluent”) nach außen finde ich besser - man müsste also nur für Felder die Getter/Setter generieren - also genau das, was Lombok schon macht.
Mit nem neuen Schlüsselwort (vor das Feld property schreiben oä) ist man dabei doch wesentlich eingeschränkter als mit Annotations, die zusätzliche Argumente haben können oder bei denen man mit Meta-Annotations arbeiten kann.

Aber ist nur meine Meinung, die meisten sehen das vermutlich anders…

Du musst die Felder selbst ja nicht exponieren. Auch bei Properties gibt es immer noch die Möglichkeit für Getter und Setter. Für ein DTO ist es aber sinnvoll, das Property zu setzen. Da gibt es kein Geheimnisprinzip. Ein Setter (im Sinne von OOP) kann und darf aber mehr. Jetzt heißt es bei einigen aber nicht mehr setValue(...) sondern updateValue(...) oder anders um zu zeigen, dass es nicht nut den Value setzt. Das finde ich wirklich unschön.

Mit ‘benutzen wie normale Felder’ meinte ich, dass man sie von außen eben wie normale Felder benutzt, auch wenn intern der Setter benutzt wird :wink:

Naja, setter sind im Sinne von OOP generell schon zweifelhaft :stuck_out_tongue:

Bis auf DTO sind Setter doch eher selten, von daher seh ich da keinen wirklichen Grund für properties. Den Lombok-Weg fänd ich da einfacher - zumindest seh ich da keinen Vorteil für properties.
Spwas wie ein nicht finales Feld, was nur einen public Getter haben soll, wäre damit ein @Getter, mit properties wäre das wieder mehr Aufwand (zumindest in den üblichen Umsetzungen) - dafür eine öffentliche API fände ich begrüßenswerter als ein neues Sprachelement.

In Kotlin wäre das private var <fieldname> internal set. C# ist bei mir schön länger her, aber da gibt es so etwas wie {private set; public get} Die Annotation @Getter kommt aus einem Framework. Ist nicht Teil der Sprache. Muss von der IDE unterstützt werden (oder benötigt immer ein Bauen des Projektes).

Und das Problem dabei ist welches? :wink: Eine Sprache mit “schlankem” Umfang ist doch ganz angenehm…
Und man könnte es genauso zum Teil der Sprache machen, wie man das mit properties machen würde. Spricht ja nichts gegen eine API, wofür das JDK dann direkt eine Standardimplementierung bereithält (wie es z.B. beim Compiler geschehen ist).

Du meinst, genauso wie bei properties? :wink: (Mit dem Unterschied, das Support für Annotations halt schon vorhanden ist…)

Mein Problem ist generell, dass man Frameworks kennen muss - sowohl die IDE als auch die Entwickler. Meiner Meinung nach, handelt es sich hierbei um ein sprachliches Feature, welches benötigt wird. Da muss es keine Frameworks zu geben. Und sprachliches Features werden natürlich von IDEs unterstützt.
Warum sollte es das nicht in der Java Sprache geben? Nicht umsonst haben alle anderen größeren Sprachen so ein Feature bereits enthalten.
Eine Sprache, bei der ich Frameworks für Extensions nutzen muss, ist es eben nicht mehr schlank. Ich wüsste auch nicht, wo genau dafür eine API benötigt wird. :slight_smile:

Ja, sprachliche Features müssen von der IDE unterstützt werden. Und dann unterstützt die IDE Java 6 bis 10 und ich weiß, die sprachlichen Features funktionieren. Lombok muss aber nicht unterstütz werden. Schon gar nicht in allen Versionen.

Annotationen finde ich (persönlich) dafür unpassend. Mit der Begründung könnte man auch alle Modifier durch Annotationen ersetzen:

@private
@final
int value

Naja, die einen sehen das als grundlegendes Feature einer Sprach - die anderen halt nicht.
Mit der Begründung, dass andere es haben, könnte man aber auch so einiges einführen :wink:

Und kennen muss man Sprach-Features genauso :wink:

Die Sprache wie schlanker, wenn man mehr dazu nimmt? Interessante Sichtweise :wink:

Gibts irgendeine IDE, die keine Annotations unterstützt? :wink:
Wenn man die API und eben eine Standardimplementierung bereitstellt, würde sie genauso unterstützt werden, wie jedes andere Sprach-Feature.

Naja, und mit der Gegenteiligen Begründung alle Annotationen durch Sprachfeatures ersetzen - wer wollte nicht schon immer ein deprecated-Keyword haben :stuck_out_tongue:

Ist halt immer ein Abwägen zwischen Sprach-Feature oder Ansatzpunkt für Erweiterung - ich bin eher Fan von letzterem und vor allem kein Fan von properties :stuck_out_tongue:

Schnappt euch das Popcorn, es geht los :corn: :popcorn:

Ja, und anders herum kann man immer begründen, dass es nicht in die Sprache gehört. :slight_smile:

Nein, Lombok wird offensichtlich benutzt, weil diese Feature in der Sprache fehlt. Das ist mittlerweile eines der meist genutzten Frameworks. Da es aber nicht zur Sprache gehört und trotzdem von vielen genutzt und gekannt werden muss, wird es eben komplizierter.

Zum einen: Ja, die gibt es. Zum anderen müssen nicht nur Annotationen gekannt werden, sondern auch deren Bedeutung. Die IDE kann Lombok-Getter ohne Compile nur deshalb auflösen, weil es dafür ein Plugin gibt, dass das übernimmt. Das ist bei alles Code-Generatoren so.

Naja, das wäre mir persönlich noch fast egal. Aber @NotNull darf ruhig direkt ein Sprachfeature sein.

Annotationen sind in der Regel ein Mittel um Code zu erweitern, der nicht direkt mit der Sprache umgesetzt werden kann. Z.B. Interceptor. Die ist vor allem für Frameworks notwendig. das JDK selbst bringt gerade mal 10 Annotationen mit sich. Und @Override und @Deprecated dürfen ruhig direkte Keywords sein.

Beteilige Dich einfach an der Diskussion oder bleib weg.

Die die keine Annotations unterstützen, würden dann aber wahrscheinlich auch keine properties unterstützen…

Und zumindest letzteres könnte man durchaus auch anders von IDEs unterstützen lassen - genauso wie man das bei properties auch müsste :wink: Ich würde nicht erwarten, dass sich beide Varianten in der Umsetzung groß unterscheiden würden, Anpassung wären bei beiden Wegen nötig.

Dann aber bitte “richtig” und nicht nur als gleichwertig zur Annotation :wink: (BTW, @NotNull wird zB von Lombok beachtet und im Setter passend behandelt).

Naja…fast alles, was mit Annotations erreicht wird, kann man auch in Java direkt umsetzen. Und die meisten Dinge könnte man auch mit Schlüsselwörtern ersetzen.
Das kann man wieder als Argument in beide Richtungen sehen…

Nach der ganzen Diskussion hier (und nicht böse oder abwertend gemeint, sondern interessehalber):
Hast Du mit einer Programmiersprache, die Properties unterstützt schon tiefere Erfahrungen?

Ja, und bisher sagte mir der “alte Java-Weg” immer mehr zu.