Lombok offers more than data classes, so Java records obviously cannot replace it completely. However, @RequiredArgsConstructor makes the code harder to understand. I prefer a visible constructor that shows which parameters a class needs. With modern tools like IntelliJ IDEA, generating (and updating) a constructor is easy, and the visual noise can be reduced by folding the constructor when it is of no interest.
Annotations like @RequiredArgsConstructor also encourage poor style, because there is no room for validation inside the constructor. At most, @NonNull adds null checks, and that is all. Lombok still offers many annotations that promote bad practice or have been superseded by the language itself, e.g. @Setter (mutability without protecting invariants), @Value (records) or @Cleanup (try-with-resources).
@Slf4j can easily be replaced by a single line of code (with the Log4j 2 API, even without specifying the class name).
Lombok's builders are actually useful, since Java has no named parameters with default values (as Kotlin does).
Regarding the "Dark Magic" section: just because other frameworks like Hibernate apply their own flavour of dark magic doesn't make it any better. Such magic should be kept out of the functional core of application code. The more magic is applied, the more problems can occur (e.g., the correct order in which tools apply their magic). This is essentially accidental complexity introduced to improve developer experience, but in the age of AI this may be the wrong optimization.
If you write modern Java, Lombok really doesn't add much.
But you could save some token with Kotlin, too. The language is a bit less "magic" and compiles faster. So, Kotlin might be a sweetspot for AI code generation. Go is probably another good candidate.
I liked Scala a lot, but it also caused some real world problems like different, partly incomprehensible coding syles or compatibility issues. Although the concise syntax could help to save some token, I guess that Scala is not the best language for AI. Other languages like Java or Go are more explicit and clear to the reader - and the AI. The elegance and conciseness simply doesn't matter so much anymore.
I could imagine some AI powered personal portal. This would basically answer the question "What is important and interesting today?". But that would have nothing in common with the old portals like Lycos.
I've experience severe problems with Scala in teams with different skill levels or programming styles. Sometimes Scala code was very cryptic. As much as I like the elegance of the language as such, I've given up on it completely because it is not a good fit for industrial software development in my opinion.
An interesting example to look at is Java vs. Kotlin. While Kotlin is a bit easier and definetly more fun, it didn't manage to gain a big market share in the Java space so far. I guess that this is the case, because Java is good enough and seems to be the safer bet (at least for managers).
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty okay.)
On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.
Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.
At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.
i am building my own framework on top of it[1].
the biggest thing for me was it was rewritten on virtual threads from grounds up. no vertx. no netty, lesser indirections.
This article looks a bit superficial to me. The cloud has definitely advantages, like having the same data on all devices and it provides some kind of backup. The mentioned downsides could be adressed by better software archticture or e2e encryption.
> The cloud has definitely advantages, like having the same data on all devices
That's not an advantage for the user at all, is it?
> and it provides some kind of backup.
You can backup user data in an offline-first app. Better even: you can let the user backup their data themselves!
> The mentioned downsides could be adressed by better software archticture or e2e encryption.
The article is superficial, but they mention at least one thing that cannot be addressed this way: what happens when you are offline or have a very slow connection?
It really boils down to one simple fact, IMHO: offline-first is harder to do. It is better for the users, but it is harder to do for the company doing it, which means it is more expensive. Companies are there for the profit, not to please the users.
> That's not an advantage for the user at all, is it
Of course it is an advantage. I tend to access most of my apps and services from both the PC and the smartphone, having data shared across the two is a deal breaker for the very vast majority of them.
> Better even: you can let the user backup their data themselves!
Whilst that's better for a small audience of techy types (most here, I'd guess), you know that's not true for most users, right?
Like people used to lose work on hard drives and laptops that they hadn't backed up all the time and its much, much rarer now (OK, I don't have data beyond anecdata but still).
I do yes. It's good to have a choice. Many times the reason there is not a proper local export is that it would take more work to implement properly, and it doesn't bring money to the company.
Again: companies exist to maximise profit. When making the product worse (or not making it better) improves their margin, they go for that. They don't care about the users, that's a big lie. A company fundamentally cares about profit. If competition or regulations mean that their profit is correlated to the users satisfaction, then they will have to work for that. But they don't do it "because they care about the users", ever.
The better software architecture is huge - if done right. It's the difference between cloud-only, local-only, and local-first. Not all apps are entirely easy as local-first, but you can often get 80-90% of what you need as that; and leave sync and collisions as rare situations to be handled manually.
Annotations like @RequiredArgsConstructor also encourage poor style, because there is no room for validation inside the constructor. At most, @NonNull adds null checks, and that is all. Lombok still offers many annotations that promote bad practice or have been superseded by the language itself, e.g. @Setter (mutability without protecting invariants), @Value (records) or @Cleanup (try-with-resources).
@Slf4j can easily be replaced by a single line of code (with the Log4j 2 API, even without specifying the class name).
Lombok's builders are actually useful, since Java has no named parameters with default values (as Kotlin does).
Regarding the "Dark Magic" section: just because other frameworks like Hibernate apply their own flavour of dark magic doesn't make it any better. Such magic should be kept out of the functional core of application code. The more magic is applied, the more problems can occur (e.g., the correct order in which tools apply their magic). This is essentially accidental complexity introduced to improve developer experience, but in the age of AI this may be the wrong optimization.
If you write modern Java, Lombok really doesn't add much.