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 ;)

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.

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.

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

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.

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.

Why would you need a copy method for an immutable record?

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.

Python's dataclasses have a "make a copy with these fields changed" function that's rippingly useful for immutable records.

How would inheritance, mutability and an arbitrary, presumably wrong and misguided "copy method" be a feature?

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...

Copy methods are in the works, and Java's pattern matching will be better than Kotlin's.

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