Projekt Lombok – Cool, aber mit zu viel Magie?

1 Kommentar

Andreas gab mir kürzlich den Tipp eine nette Bibliothek anzusehen: lombok. Lombok erweitert den Java Kompilierungsvorgang, so daß bestimmte Klassen mit weniger unnötigem Code auskommen da dieser bei der Kompilierung erzeugt wird.

Project LombokIch bin total begeistert, so reicht es aus @Data an eine Klasse zu schreiben und schon werden die getters und setters, toString() und die hashCode() und equals() Methoden generiert. Im Prinzip funktioniert das so wie die magischen Methoden in Groovy. Ich mag das, da ich mich mehr auf die wichtigen Methoden kümmern kann ohne mich durch hunderte von unnötigen Zeilen scrollen zu müssen. Ich mag auch, daß so niemand Getter oder Setter für Seiteneffekte missbrauchen kann. Es passt auch in den agilen Prozess: Es beseitigt muda.

@SneakyThrows ist genial! Ich hasse die UnsupportedEncodingException auch wenn ich klar „UTF-8“ spezifiziere, welches garantiert immer vorhanden ist.

Vor allem mag ich den Implementationsansatz: Lombok hängt sich in den Kompilationsvorgang und generiert den entsprechenden Code für die Annotations. Das Eclipse Plugin sorgt dafür daß Eclipse diese (nicht im code vorhandenen) Methoden anzeigen kann.

Lombok ist cool und ich hoffe es wächst weiter.

Aber leider ist die Lombokmagie schwer zu verstehen. Im Code findet sich keine Erklärung dafür wie die Klasse zur Laufzeit sich verhalten wird. Dafür, daß der Code letztendlich nur etwas aufgeräumt wird, muss der durchschnittliche Entwickler viel lernen.

Man denke auch an die Wartung: Wenn man jetzt Lombok verwendet und in 2 Jahren niemand mehr von Lombok spricht, weil das Projekt tot oder nicht mehr cool ist, wer soll dann ein weiteres Jahr später den Code warten können? Man wird sich wundern wie der Code funktionieren konnte, kompiliert er doch ohne Getter und Setter nicht mehr.

Anmerkung zu Gettern und Settern: I glaube man benötigt sie eigentlich gar nicht, sondern generiert sie nur weil Framework X sie braucht. Getter und Setter sollten keine unerwarteten Seiteneffekte haben. Also genau so wie sie Lombok generiert. Doch dann stellt sich die Frage warum man diese Methoden überhaupt braucht und die Felder nicht einfach public macht. Ich denke der Grund ist der, daß man in Wirklichkeit keine Getter und Setter auf Felder braucht, sondern eigentlich Domänenmethoden haben möchte. Ganz einfach ohne unnötige Getter und Setter und ohne Lombok 🙂

Lombok ist definitiv ein netters Spielzeug für erfahrene Entwickler. Und es ist auch sehr mächtig mit einer erkennbar guten Tendenz für zukünfigie Entwicklungen. Für private Projekte werde ich es sicher nutzen.

Was denkt Ihr über das Verhältnis von Nutzen zu Verwirrung. Ist es vielleicht sogar konstant, so daß jeder Nutzen immer Verwirrung bringt?

Fabian Lange ist Lead Agent Engineer bei Instana und bei der codecentric als Performance Geek bekannt. Er baut leidenschaftlich gerne schnelle Software und hilft anderen dabei, das Gleiche zu tun.
Er kennt die Java Virtual Machine bis in die letzte Ecke und beherrscht verschiedenste Tools, die JVM, den JIT oder den GC zu verstehen.
Er ist beliebter Vortragender auf zahlreichen Konferenzen und wurde unter anderem mit dem JavaOne Rockstar Award ausgezeichnet.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Robert Krombholz

    2. Oktober 2009 von Robert Krombholz

    Hi,

    this is my point of view:

    if you can not live with the boilerplate code requirements that comes with the usage of Java you should get fimilar with one of the many alternatives that luckily we have today (even on the JVM).

    This library makes it easy for everyone to get programs running based on a modification of a very well known, robust and solid language.

    Looking at the big picture this will cause a lot more confusion than bringing value to developers.
    My opinion would be completely different if every Java deloper would be fimilar with this library.

    This will not happen as long as something like this is not part of the language specification.

    Anyway nice to see what people these days are inventing to get around the boilerplate code that every Java developer as written uncountable times over the last 10 (or even more) years.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.