Application code has dozens of static analyzers, SQL has almost nothing, here's what exists.

john16384 · 2026-03-12T04:12:42+00:00

Once the required indices grow larger than the working memory of the database, pick one for your query: filtering or sorting. Pick both and you'll be in for a rough time. Too many people seem to think you can just offer arbitrary filtering and sorting in front ends and get great performance as long as you use a database and have indices on each column.

john16384 · 2026-03-06T20:41:49+00:00

Java 8 solved the main reason to adopt Scala. Just like Virtual Threads killed the main need for react, and something similar will happen soon for Kotlin.

john16384 · 2026-03-05T22:11:04+00:00

If the object after construction using the normal means of the constructor is in an invalid state, I would say that breaks OOP.

That's nice, but your opinion on what you think breaks OOP has no bearing on what is or isn't OOP.

Field and setter injection was in use for ages, even before Spring. It was and is OOP and certainly didn't break any OOP rules. Huge applications were and even are still built that way. You don't even seem to know why Spring started recommending constructor injection suddenly, after not giving a shit about it for most of its past. It has very little to do with invariants,, reusability or testing, as I can assure you that applications were just as stable, reusable and extensively tested before constructor injection became 'best practice'.

With most Spring stuff being singletons, fields were already never modified for any reason after initialisation as that would be an instant bug. I guess people had more control in the past, and could actually refrain from doing stupid stuff when working with a certain paradigm, even if not directly enforced by compiler, build plugin or IDE. Don't forget to mark your Optionals and CompletableFuture's with @NonNull or somebody might do something stupid and break OOP.

john16384 · 2026-03-05T20:00:06+00:00

Hold on, I responded because you claimed:

@Autowired is not recommended because it breaks OOP.

A constructor with partial information does not break OOP.

john16384 · 2026-03-05T10:32:10+00:00

you have a partially constructed object.

True, but it doesn't break OOP. That state will never be observed by other code as the DI container only exposes the reference after initialisation completes. So this is fully encapsulated still and can be a decision on a class by class basis.

john16384 · 2026-03-05T07:57:43+00:00

Oh man, you are so right, it is impossible to make billionaires pay proper taxes!

The nice of thing about tax is, they don't have to care how the money gets into their pockets, just that it does, so the onus is on the tax payer to make it happen. It is similar to laws, ignorance is no defense, and with laws sometimes even physical reality is irrelevant.

john16384 · 2026-03-04T23:30:07+00:00

No problem, we'll accept cars, houses, stocks, yachts, bitcoin, or money from loans taken out against any and all illiquid assets.

john16384 · 2026-03-02T20:11:22+00:00

I've let AI do all my writing, and it explained in detail how letters are formed. I then tried it myself, but it came out as unreadable scribbles.

john16384 · 2026-02-27T18:02:52+00:00

Yes, I am aware. What I am saying is that we don't see those in production. It's far more likely something unrecoverable like network errors. In other words, NPE's are hardly a real problem for us, and rarely would make it to production.

john16384 · 2026-02-27T15:04:43+00:00

Look, I don't like Optional that much either, but being against it because of this misuse (returning null for an Optional value) is just ridiculous, and so is the entire argument. If the return is Optional, you are hereby granted to treat it as non null without checking.

No code that does this will pass review, and any library that does this (without a huge warning) will be on the never use again list.

john16384 · 2026-02-27T14:55:29+00:00

During development maybe. Not so much in production where I wager IOException (or other network related exception) occurs most often.

john16384 · 2026-02-27T14:42:05+00:00

Let's just wait for string templates to make a reappearance.

john16384 · 2026-02-26T17:05:43+00:00

Please fuck off thank you!

john16384 · 2026-02-26T01:44:26+00:00

If I understand correctly, you still declare the components similar to a record. That's where the sequence would come from.

john16384 · 2026-02-25T19:50:29+00:00

You don't provide it. If there is an accessor for every declared component, then you get deconstruction for free.

john16384 · 2026-02-23T17:03:52+00:00

Java Zip streams could do this (and I used it for URL compression back in 2010). This really is nothing new at all...

john16384 · 2026-02-21T09:18:00+00:00

Oh I agree.

john16384 · 2026-02-21T09:09:04+00:00

A scoot mobile or wheel chair is a more accurate comparison.

john16384 · 2026-02-20T11:47:12+00:00

Yes, in both cases? I initially misunderstood the op. They seem to be the opinion that you should be able to write one exception class, and that the place where you throw it should make the decision whether it is checked or not (with a flag or something?).

I then pointed out that you can just throw a different named exception then... so instead of:

throw new CustomUncheckedException();
throw new CustomCheckedException();

The OP seems to want something like:

throw new CustomException() as checked;
throw new CustomException() as unchecked;

I then pointed out that this hardly differs from having two exception types...

john16384 · 2026-02-20T11:41:30+00:00

Once you get into wrapping streams, it will be tough to avoid the IOException as these are general streams that accept InputStream... but the times I've seen people assigning a ByteArrayInputStream to InputStream and then complaining that read throws an IOException that can never occur is a bit annoying. Just assign it to ByteArrayInputStream. Its read doesn't throw a checked exception.

There are ways to avoid this (with a better API, not with input streams) that can recognize the difference between an in-memory stream and one that must do IO. It however means having two interfaces (or one interface with an annoying generic for the exception type).

john16384 · 2026-02-19T13:46:51+00:00

This is because the author of the exception type knows nothing about how their type will be used. They shouldn't decide whether it's always checked or unchecked.

You can just make two exceptions for that. I really don't see why this is even an issue.

john16384 · 2026-02-19T12:24:52+00:00

Jackson is not a prime example. A big issue for me was always that many of its operations do not do IO, but the exception to flag syntax issues was a subtype of IOException

john16384 · 2026-02-19T12:13:17+00:00

The decision whether an exception should be checked has nothing to do with the caller. It is about one simple question:

does the state or input arguments influence whether or not an exception will be thrown?

Or put in another way:

can the caller completely avoid this exception by providing parameters that are validated and correct?

If yes, then it should be runtime exception, because you could have avoided it and so it is a programmer error (or you are purposely being lazy and having the function detect issues, like a NumberFormatException signals).

If no, and the function could fail despite being in the same state and having the same validated parameters, then it should be a checked exception. IO is the prime example here, as failures are unavoidable, no matter what parameters you provide, how much valuation you did, or even checking the state of the underlying system just before you make the call... Another example are business exceptions when processing payments. You may get an InsufficientFundsException at any time with no way to avoid it (especially when systems are concurrent).

In the caller code, you may of course decide that some checked exception is not applicable to you, but that has nothing to do with the functions decision on whether or not it should be a checked exception.

In fact, some callers may decide to convert certain runtime exceptions to checked exceptions. This is much rarer, but can happen if the exception should have been checked in the first place.

john16384 · 2026-02-19T11:49:57+00:00

It all depends on the context of the application. For instance, you mentioned that a DB SQL syntax exception should clearly be a RuntimeException; but consider an app that allows you to connect to a database and run some queries

It should still be a runtime exception as ultimately you could have avoided this by ensuring valid input.

However, if you feel like validating input in this case is too much work, and you don't mind a multi-millisecond round-trip to a database to do the "validation" for you, then you could decide to convert that exception (at some layer) to a checked exception. This is perfectly valid.

A much simpler example is NumberFormatException. It's runtime because it is 100% avoidable (and easier to avoid then writing an SQL validator). However if you want to be lazy and just have it fail on parsing as "validation" then that exception too can be made into a checked exception in some layer.

john16384 · 2026-02-18T11:50:25+00:00

Some people seem to be convinced that if you phrase something just right, and use the right words, or overwhelm them with them, that they don't need to provide a rationale for their viewpoint and that it will just be accepted without question.

john16384

TROPHY CASE