← Back to context

Comment by tharkun__

5 years ago

It's weird to me how you find the magic of spring sad while you find the magic of Lombok acceptable.

Lombok requires that you use a supported build system and IDE and while all the currently relevant ones are supported that is no guarantee. Needs plugins and agents that support your various tools' versions including the JVM itself. I've been in that hell before with AspectJ and the aspectJ compiler vs eclipse plugin (version incompatibilities that made it impossible to work efficiently until they fixed it all up).

Disclaimer: last company we used Lombok. Current company we are switching certain things to Kotlin instead. data classes FTW for example. I do miss magic builders. Builders are awesome. Building the builder is tedious ;)

11 comments

tharkun__

Reply
hamandcheese  5 years ago

Lombok magic doesn’t span across files. Look at the class, see the annotations, and as long as you have even a trivial understanding of what Lombok is, you can grok it. It’s basically like a syntax extension.

Spring on the other hand... autowired values everywhere, and at least for me (who doesn’t work with Spring day in and day out) it’s very difficult to understand where they come from.

  • tharkun__  5 years ago

    Don't get me wrong, I've used Lombok and liked it from the working with it and what it saves you aspect.

    We do use spring and I've used it for a very long time now. Nothing is magic and not understandable about wiring if you do it right. Unfortunately there are a lot of projects out there that use it in exactly the wrong way if you ask me and then I'd agree with you.

    I used to be in a company where we used XML config and everything was wired explicitly. The XML part sucked but with SpringIDE (eclipse at the time) it was Ctrl-clickable to find what's what.

    We use Java config with Spring at my current company and I can Ctrl-click my way through it all and find what's what. There's a small corner of 'package-scan'ed stuff that is evil but we are cleaning that up.

gher-shyu3i  5 years ago

Java already has records, better than Kotlin's data classes.

  • unscaled  5 years ago

    How exactly are they better from Kotlin's data classes?

    Aside from the fact Java only released non-preview support for records one month ago, they:

      - Don't support inheritance
  - Can't be mutable
  - Don't have a copy method

    While Java records are nice, Kotlin data classes are strictly more capable than Java records.

    • tharkun__  5 years ago

      FWIW I think that whether someone wants to use mutable objects or swears by immutability should be their choice, especially for interoperability with legacy code. It can be much easier to 'just go with the flow and be careful' in a legacy code base vs trying to have a clear separation of where immutability has been introduced already and where we still don't use it. Not everything is green field (in fact most stuff isn't) and not every company gives you enough time to always Do The Right Thing (TM).

      Copying objects is a well known need and there are countless libraries that try to help you with it. All with their own problems, notably runtime errors vs. compile time safety or pervasive use of reflection.