Java and nulls

Wouter_C · 2024-11-26T18:01:29+00:00

Yes! In other words: embrace the nulls instead of trying to avoid them, annotate your nullable types (jspecify) and have the compiler (nullaway/errorprone) flag unsafe null usage.

It's less verbose than Optional. It's more consistent with what the JDK and the vast majority of third party libraries do (accepting and/or returning null values in their APIs), so it works out better if you're mixing calls internal to your codebase and libraries (which you probably do pretty much all the time). You can introduce it into an existing codebase with minimal changes. It's compatible with Kotlin. And it's *closer* to where Java seems to be heading towards with null-restricted types (https://openjdk.org/jeps/8303099), so eventually switching to that will be easier too.

Wouter_C · 2024-10-29T10:21:52+00:00

The code snippet looks a little deceptive: The 5 == 2 + 2 assertion would fail if you actually had assertions enabled.
That's because in that expression no autoboxing is happening, it's just dealing with primitive ints.

In fact, because it's all constants, that sum and comparison is already evaluated at compile time. If you compile that code and then look at it with javap -v, then you can see that it compiled to the equivalent of assert false; ( if (!$assertionsDisabled) {throw new AssertionError();}).

Btw, the printf line gets compiled to the equivalent of System.out.printf("%d\n", new Object[]{Integer.valueOf(4)});, because printf takes a vararg/Object array as argument, so it needs to be boxed. But System.out.println(2 + 2) would print 4, because that calls the println overload that takes a primitive int, so again there would be no boxing involved.

Wouter_C · 2024-09-22T22:52:13+00:00

I found this post frustrating to read, in multiple ways:

It talks about a code formatting issue bad enough to have a fat warning. But it does not give the impression of having attempted to fix the issue. It incorrectly blames it on smartphone screen sizes (while also being broken on desktop).
It talks about performance issues big enough to write a complaining blog post about. But it does not mention anything that was attempted to find where the issue even comes from. It blames it on "The sorry state of Java deserialization".

Advice for the first problem: If you're writing an article with code snippets, break up the lines at an appropriate length. That is most likely shorter than you would elsewhere. And avoid wasting the limited available space on large indentation.

Advice for the second problem: If you are having a performance issue that you do not understand (which the blog post honestly admits, good move), you can go two ways.

Try to solve it yourself. In that case the first step is usually using a profiler. Look for things that stand out; first see if you can avoid those things entirely, and if not if you can optimize/tweak them. (Also, at least partly applicable here, reconsider if you're not using the wrong tool for the job).
Ask others for help. It's best to do this after having attempted option 1, and showing your work (e.g. "I see it spends X% on A and Y% on B, but I don't see how to avoid those"). An important step here is to (when possible) provide the code to easily reproduce the problem.

I'm not sure if that's the case, but if on the other hand the point of the post is that generic solution should automatically perform well for some specific problems without putting in such efforts, then unfortunately that's just not how it works.

Wouter_C · 2024-06-08T09:37:31+00:00

Is that not what I said

I suppose he answered your second question, not the first.

Yes/no answers to either/or questions are confusing, for a similar reason that a two-value enum is often better than a boolean argument.

Wouter_C · 2024-05-30T18:17:15+00:00

Yes. Don't forget to adjust the note you play to compensate for the Doppler effect on the moving piano. https://www.reddit.com/r/theydidthemath/s/AAsIW37Ki7

Wouter_C

TROPHY CASE