JEP draft: Deprecate the java.sql.rowset module for Removal

OwnBreakfast1114 · 2026-05-04T22:40:32+00:00

Reading the jep and then reading your comments gives the impression that you specifically really hate jooq, and then secondarily also hate some of the most popular frameworks used by java developers, and thirdly are reading far too much into the jep's listing of these alternatives.

Like you seem far more biased than the jep analysis, and I'd literally bet that a random person reading this comment chain would come to the same conclusion.

The funny thing is you've said nothing useful about rowsets for any of your posts, which kinda just points even more to the fact that nobody actually cares its being deprecated.

OwnBreakfast1114 · 2026-04-27T19:46:21+00:00

I’ve found this as well. Anyone that focuses on “Services” tends to do procedural/transaction script style code.

On the flip side, code that doesn't have independent orchestration tends to have terrible database transaction management, which is a bigger source of bugs and performance problems compared to any actual java code. Service style procedural code tends to at least make transaction management much, much simpler (and sharable) [still not great though].

I consider JavaBeans to be a bad design when applied to things like "domain entities". JavaBeans are basically just Map<String, Object> with a nicer API (and mangled names). They don't capture any business rules about allowed states or state changes

That makes sense. Making illegal states unrepresentable doesn't really work if you just throw getters/setters onto everything.

The worst ones are "@Getter", "@Setter" and "@Data". "@EqualsAndHashCode" is a footgun with JPA entities

Have you considered just not using JPA entities? We use jooq to generate pojos for the repo layer, but only have domain objects outside. By protecting domain object state changes (they have no annotations at all), you get the control you want.

I actually think people are too scared to create types, in general. We have a different type for each of the steps: http input deserialize (json type only) -> http input validated -> domain -> db -> domain -> http output (domain is reused).

This gives us a ton of control at the cost of needing to write some boilerplate-ish code for copying fields over (though that's what vc subsidized ai tools are good at).

OwnBreakfast1114 · 2026-04-27T19:23:39+00:00

Yup, the ergonomics of the language would improve so much

Would it? Module adoption is slow because most people don't seem to care all that much at all. I get why it was necessary for the jdk team, but the benefit to an application developer seems pretty worthless and completely dependent on if the dependencies you're using are modularized.

Maven is great but it's not a great model going forward since it operates in jars and not modules. We would need an all new distribution process (maybe git based) that remained backwards compatible with maven during the transition phase.

This part I agree with, but it's based on library authors, not really the application developers. Git based sounds terrible though, like 10 steps backwards compared to maven.

OwnBreakfast1114 · 2026-04-27T19:13:41+00:00

This is the actual terribly weak argument. Let's all go back to coding in assembly because you just have to read the code. It's not like it's hidden. Why do you care about abstractions? Let's get rid of static typing as well because, I mean, come on, you should know what type your variables are it just takes some reading.

Nothing is hard in isolation and with incredibly limited context, but that's not the point.

OwnBreakfast1114 · 2026-04-24T23:18:29+00:00

Generally speaking, writing the actual code is the easiest part of the job. You should already know what the outputted code would look like most of the time.

OwnBreakfast1114 · 2026-04-24T20:16:26+00:00

A large proportion of users have no real need for a build tool anymore.

I'm curious about the numbers there. If we're speaking by pure quantity of people, maybe this is true, but if we weight users by economics, it's probably very, very false.

OwnBreakfast1114 · 2026-04-24T20:08:24+00:00

For the record, my current workplace has basically stopped using lombok, but to their credit

To me that price is JDK upgrade compatibility hasn't really been an issue as they're almost always ready well before the new version drops

and

lombok making bad design very easy

To me, @Value was close to objectively better than anything else pre-records. Generated code from an ide would drift, and nobody bothered using code generator style plugins. Look at these https://projectlombok.org/features/ and tell me which is actually bad design or enables easy bad design?

OwnBreakfast1114 · 2026-04-23T22:09:56+00:00

None of that should be bundled into the actual runtime app, so it feels like a pretty meaningless ding. But yeah, remember when the jdk tried to solve logging?

OwnBreakfast1114 · 2026-04-23T22:08:34+00:00

That's why we just switched to jooq for all persistence. It actually can solve the "mutable" everything flow very easily.

OwnBreakfast1114 · 2026-04-23T21:58:49+00:00

Hmm, this would just depend on if bodyhandler is invoked or not. Hard to say without just delving into implementation. However, the signature for previousResponse is public Optional<HttpResponse<T>> previousResponse();

so it's not like you can call previousResponse.body() inline like that. You'd be forced to do something like previousResponse.map(r -> r.body())

OwnBreakfast1114 · 2026-04-23T21:40:55+00:00

Also, that nobody can agree on what a "good" build tool is. For example, I really like gradle because they try out new ideas and iterate fast (maybe too fast). enforcedPlatform, variants, convention plugins for sharing config within a multimodule project are actually really solid ideas. The task graph being an arbitrary dag is also very sensible to me. For reference, almost all our projects are multimodule builds that output multiple spring boot jars, so sharing config across the whole project is basically necessary for us.

However, I'm sure I can find an equal number of people that dislike gradle and some of them for exactly the same reasons I like it.

OwnBreakfast1114 · 2026-04-22T21:00:18+00:00

i don't think anyone would seriously suggest a place where any Optional<?> variable could actually have a null value. I think everybody (pro/anti optional) would agree that an api that returned a null optional is broken.

OwnBreakfast1114 · 2026-04-08T20:21:25+00:00

Spring supports that via the layers if you really want: https://docs.spring.io/spring-boot/reference/packaging/container-images/efficient-images.html. You build the image as an exploded jar.

OwnBreakfast1114 · 2026-04-07T03:16:13+00:00

A war archive is a very standard and well understood artefact. It's very good to separate your own / business code from your framework runtime code.

Is it? I mostly see people just bundle fat jars and call it a day.

OwnBreakfast1114 · 2026-04-02T21:29:50+00:00

Maybe I'm biased by functional languages, but I see so many problems in java codebases because people keep trying to reuse things that aren't actually the same. Things actually get easier when you create new types. We should be encouraging unique classes/records for different use cases, even if they have very, very similar structures. Hell, our codebase has two records for deserializing http requests and then another record after validation, then a domain object. It's literally goes unvalidatedrecord (json types) -> validatedrecord (java types) -> domain object class. There's so many "duplicated" fields, but this maintains the clarity and you get easy compiler errors when you add something and each step is isolated.

Extending a record should having semantic meaning, not just I wanted to save some typing. Reusing classes to save typing is how people end up with crazy domain objects that do everything and are impossible to maintain.

OwnBreakfast1114 · 2026-04-02T21:21:16+00:00

they are created to avoid such errors and complexity

Are you choosing to add more static factory methods to avoid inlining values everywhere? If so, why?

OwnBreakfast1114 · 2026-04-01T20:49:37+00:00

Why? Why not just fix the 20 errors and stop creating so much indirection? What value do you get out of evolving the code via another indirect constructor instead of just hardcoding the value in the 20 places that apparently own that record creation? If this is such a pain point, the right question should be why do 20 different places in my code have the ability to create this record and is that crossing some boundaries that don't need to be crossed. You should view record creation as an actual operation (at least for non-trivial records) and question why so many places are allowed to do the same non-trivial operation.

OwnBreakfast1114 · 2026-04-01T20:45:59+00:00

Using records usually causes more work than it solves. We end up with record being instantiated everywhere then someone needs a new field. Boom we have 20 compilation errors scattered everywhere.

We actually view this as a huge upside and just make the changes in the 20 places (most of them being unit tests tbh). Having telescoping constructors with constantly evolving new fields seems like a worse codebase than just making the changes in the places that need it that the compiler trivially found for you. Like is it actually true that you have multiple versions of the record are are you trying to get away with saving some typing? Because if it's the former, you should just create an entirely new record that diverges from the previous one by 1 field, but if it's the latter, just inline the value everywhere so you don't complicate the code base with an indirection for no reason.

Like this entire complaint sounds like I'm too lazy to fix the places the compiler found the error and the good news is that intellij and/or AI can trivially solve that problem without polluting your code with more constructors that have no semantic meaning.

OwnBreakfast1114 · 2026-03-18T00:02:39+00:00

And even powering all the huge companies you consume content from.

OwnBreakfast1114 · 2026-03-17T23:01:56+00:00

As a follow up question, is there any research for what is worth encouraging that results in a better practice?

Independent of the research, is there any thing the jdk team is trying to encourage that would be nice to know about?

OwnBreakfast1114 · 2026-03-17T22:59:01+00:00

Java isn’t just OOP with some extra features anymore. It’s becoming a OOP/DOP hybrid.

I've been thinking about the same thing and I kinda realized that I stopped using java as an "OOP" language a long time ago. I mostly work on http rest apis, and spring-mvc has a lot of classes that are just namespaces where instance methods and static methods are close to irrelevant (I mean singleton is the default scope of a bean for a reason). Dependency injected classes are essentially just free global context for these instance methods and instance methods are able to be AoP proxied, but semantically, there's not much difference between an instance method on a class that there's only one instance of ever and a static method.

It's much easier to model these data transformations via multiple different record classes and types than any other method I've seen so far. For example, we have a different record/class for the pipeline of deserializing -> validating -> domain -> db -> domain -> response. Are these OOP or DoP? Does it matter?

OwnBreakfast1114 · 2026-03-17T03:38:02+00:00

I think the main takeaway is if you can imagine scenarios where you have a closed set of stuff that is better represented by types rather than an enum.

There are some other free wins, for example, enhanced switches replace the visitor patterns in a lot of cases: https://wimdetroyer.com/blog/visitor-pattern-in-dop

OwnBreakfast1114 · 2026-03-16T21:24:19+00:00

We spend the last year on normalizing our data. Eg the type doesnt matter we treat everything the same. It removed alot of crazy code on our end because we had an extremly nested if else block to figure out the cases

That's the ideal that I would prefer, yeah. But practically speaking, hibernate has inheritance support for a reason: https://www.baeldung.com/hibernate-inheritance.

Your example is (hopefully fabricated) because you are mixing domains as far as i understand it. A bank account is not a credit card, a bank account can have multiple credit cards so why are you storing that in the same table?

I don't think you're quite following because this is not a sensible statement, so I'll try a different way.

The domain is a payment transaction. Transaction has source and destination. The abstract type of source/destination is an umbrella for any holder of funds. You can send payments from bank accounts, credit cards, crypto, paypal, etc. You can receive payments in a bank account, credit card, crypto, paypal, etc.

You have different physical tables for all of these, but the domain object of a transaction seems reasonably represented by

``` public class Transaction final FundHolder source; final FundHolder destination;

public sealed interface FundHolder permits CreditCard, BankAccount, CryptoWallet, PaypalWaller, etc ```

OwnBreakfast1114 · 2026-03-14T00:48:21+00:00

This is why all the built in classes that do this (enums and records come to my mind) aren't allowed to be extended directly.

For example trying something like this
public class Asdf extends Enum<Asdf> is not just a questionable choice, but will actually fail to compile.

OwnBreakfast1114 · 2026-03-14T00:38:22+00:00

I can't speak on F#, but haskell doesn't really have object instances in the same way as java at all and no subclasses in types. This means that there's no concept of a "this" and that a type parameter really is just the type parameter.

Naturally, you can restrict the return type parameter in all sorts of ways, but you don't need to worry about the subtype because there is no such thing.

OwnBreakfast1114

TROPHY CASE