5 ms·

I use java8 at my dayjob. It's been years since I did any of that, as Lombok and spring boot generate that code for you. Immutable classes get a @Value and ma

I use java8 at my dayjob. It's been years since I did any of that, as Lombok and spring boot generate that code for you. Immutable classes get a @Value and maybe @Builder annotation, muteable ones get @Setters etc. Springs auto wiring for beans is sadly magical however, so much harder to figure out what went wrong if you have any issues...

tharkun__ 6y 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 ;)
- gher-shyu3i 6y ago
  Java already has records, better than Kotlin's data classes.
  - unscaled 6y 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.
    - wwwwewwww 6y ago
      Why would you need a copy method for an immutable record?
      - TomSwirly 6y ago
        Python's dataclasses have a "make a copy with these fields changed" function that's rippingly useful for immutable records.
      - etripe 6y ago
        When applying events, for instance. In F#, you could do: match msg with | IncreaseCounter cnt -> { model with Count = model.Count + cnt } | DecreaseCounter cnt -> { model with Count = model.Count - cnt } | ResetCounter -> { model with Count = 0 } | ChangeRubric name -> { model with Rubric = name, Count = 0 } The "with" says: copy the original record by value, but change these fields. For completeness' sake: F# also has implicit returns, so the bit between brackets is the function's return value.
    - HelloNurse 6y ago
      How would inheritance, mutability and an arbitrary, presumably wrong and misguided "copy method" be a feature?
      - unscaled 6y ago
        Why do you think copy methods are "presumably wrong and misguided"? For the rest, I agree that in 99% of the cases inheritance and mutability are not needed if you're using greenfield Kotlin libraries. But they are unfortunately often necessary in the Java world. Mutable data classes are especially quite useful for reducing boilerplate when creating classes that implement the Fluent Builder pattern, which is unfortunately quite necessary if you don't have a copy method...
    - gher-shyu3i 6y ago
      Copy methods are in the works, and Java's pattern matching will be better than Kotlin's.
    - tharkun__ 6y 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.
- hamandcheese 6y 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__ 6y 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.
the-alchemist 6y ago
Lombok is great, but Immutables is even better! https://github.com/immutables/immutables https://github.com/immutables/immutables

tharkun__ 6y 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 ;)

gher-shyu3i 6y ago
Java already has records, better than Kotlin's data classes.
- unscaled 6y 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.
  - wwwwewwww 6y ago
    Why would you need a copy method for an immutable record?
    - TomSwirly 6y ago
      Python's dataclasses have a "make a copy with these fields changed" function that's rippingly useful for immutable records.
    - etripe 6y ago
      When applying events, for instance. In F#, you could do: match msg with | IncreaseCounter cnt -> { model with Count = model.Count + cnt } | DecreaseCounter cnt -> { model with Count = model.Count - cnt } | ResetCounter -> { model with Count = 0 } | ChangeRubric name -> { model with Rubric = name, Count = 0 } The "with" says: copy the original record by value, but change these fields. For completeness' sake: F# also has implicit returns, so the bit between brackets is the function's return value.
  - HelloNurse 6y ago
    How would inheritance, mutability and an arbitrary, presumably wrong and misguided "copy method" be a feature?
    - unscaled 6y ago
      Why do you think copy methods are "presumably wrong and misguided"? For the rest, I agree that in 99% of the cases inheritance and mutability are not needed if you're using greenfield Kotlin libraries. But they are unfortunately often necessary in the Java world. Mutable data classes are especially quite useful for reducing boilerplate when creating classes that implement the Fluent Builder pattern, which is unfortunately quite necessary if you don't have a copy method...
  - gher-shyu3i 6y ago
    Copy methods are in the works, and Java's pattern matching will be better than Kotlin's.
  - tharkun__ 6y 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.
hamandcheese 6y 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__ 6y 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.

the-alchemist 6y ago

Lombok is great, but Immutables is even better! https://github.com/immutables/immutables https://github.com/immutables/immutables