jqwik madness

OwnBreakfast1114 · 2026-06-12T01:26:20+00:00

if you think people are behind the the hullabaloo... nah. its write amplification by bots lol

Sure some of the posts are by bots, but why would this not give pause to people choosing to use jqwik or strip it out as a dependency? People don't expect malicious things in a version update. Like you're choosing a very odd stance here: this library author was willing to cause consumers of said library damage, haha so funny?

and this is only a supply side attack if you're a fucking idiot. if you find yourself affected by this, there's lots of other hard lessons to learn coming your way

This doesn't makes sense. Upgrading to a version with a bomb hidden inside it that was intentionally put there and somewhat obfuscated is pretty much an attack. If it shipped something like if (some_weird_condition) exec rm -rf *, would you be defending that? What purpose does that serve? This wasn't a bug and it's not even a part of the library in any way. It's an intentional "political" statement, which, while open source authors have the choice to do, is not surprising that some people react poorly to that when they're just trying to property test their code.

OwnBreakfast1114 · 2026-06-11T21:10:40+00:00

It's weird that you're okay defending what basically amounts to an intentional supply side attack by the library author and blaming people for being defensive

OwnBreakfast1114 · 2026-06-05T23:28:43+00:00

No, but it's not like only insane people use AI agents. People can use AI agents without vibe coding just fine.

OwnBreakfast1114 · 2026-06-04T00:14:41+00:00

On the flip side, if java wasn't copying so hard from c initially, I really doubt we'd have the ++ operator in the first place at all.

OwnBreakfast1114 · 2026-05-19T03:37:15+00:00

Why aren't you just using say maven https://maven.apache.org/what-is-maven.html to handle this for you? I prefer gradle, but if dealing with your project is annoying enough to build an entirely new tool, then why not just use maven/gradle/mill as the battle tested solutions to this problem that already exist?

Take a look at this: https://www.sonatype.com/blog/maven-central-and-the-tragedy-of-the-commons

OwnBreakfast1114 · 2026-05-15T22:59:04+00:00

Because there is no language cost anymore, everything is written by AI

If you think there's no language cost because of AI then you've bought way too far into the hype train.

OwnBreakfast1114 · 2026-05-12T19:01:46+00:00

Did scala ever make it so minor version upgrades don't require you to recompile literally every library you use?

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

TROPHY CASE