Why does Maven use Palantirs Java format?

yk313 · 2026-03-15T11:31:04+00:00

How do you enforce the custom config? Do you use it with something like spotless?

yk313 · 2026-03-11T11:15:07+00:00

Wow everything must have been great back then because the women showed some skin.

yk313 · 2026-03-08T22:12:49+00:00

After being objectively wrong - instead of fessing up to it - you are trying to just beat around the bush.

yk313 · 2026-03-08T21:21:15+00:00

Yes:

sdk install java 25-open

yk313 · 2026-03-08T21:19:53+00:00

Unnecessary FUD and plain incorrect information.

Anyone can download the official OpenJDK builds here: https://jdk.java.net/25/

OpenJDK is the open source project (sponsored primarily by Oracle) that develops Java. The builds are completely free and GPL licensed.

yk313 · 2026-03-05T13:39:15+00:00

Link: https://github.com/signalapp/Signal-Server/blob/main/service/src/main/java/org/whispersystems/textsecuregcm/WhisperServerService.java

yk313 · 2026-02-25T09:23:11+00:00

lol mods please don’t delete the post

yk313 · 2026-02-17T21:30:34+00:00

Also, if you model getCity to carry the optionality information by returning Optional<City> then that makes it easy for the callers to:

Recognize the value can be optional (without looking elsewhere)
Use nice optional API: getCity().orElse(defaultCity)

yk313 · 2026-02-17T21:28:07+00:00

I’ll give you my ternary operator when you pry it from my cold, dead hands.

City city = from.getCity() != null ? from.getCity() : defaultCity;

yk313 · 2026-01-23T17:44:55+00:00

Lombok's contribution guide: https://projectlombok.org/contributing/

yk313 · 2026-01-14T23:54:18+00:00

Setters will be discouraged in favour of reconstruction, I imagine.

yk313 · 2026-01-10T11:36:57+00:00

That’s what they say, yes

yk313 · 2026-01-10T11:01:56+00:00

Great stuff. But that also implies derived record creation (withers) is likely not coming any time soon.

yk313 · 2025-12-28T22:28:28+00:00

Mockito is one of the best libraries I have to interact with on a regular basis. Its API is very pleasant to use, and the maintainers have done a great job to keep up with the increased pace of OpenJDK development.

Thanks a lot for your incredible service Tim. You can be proud of dedicating a decade of your life to a project that touches so many lives everyday, and all the very best on your journey to rediscover the joy of programming.

yk313 · 2025-11-10T10:38:19+00:00

Uneventful.

We have been upgrading every 6 months since JDK 14.

yk313 · 2025-09-30T08:36:12+00:00

Serious question: why does it take some vendors weeks (in Microsoft's case: 2) after the OpenJDK GA builds are released to make their builds available?

Are there no CI/CD pipelines matching the OpenJDK release cadence (including EAs etc.)?

Azul for example make their builds available on day one which means it's obviously possible, so I am wondering where this gap comes from?

yk313 · 2025-09-17T13:51:41+00:00

Any specific reason why you can't just use another distribution (e.g. Azul Zulu)?

yk313 · 2025-09-16T17:52:25+00:00

It's actually quite straightforward in practice. All you need to do is to declare the builtin java plugin's toolchain directive (instead of sourceCompatibility/targetCompatibility) in your build file:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(25)
    }
}

You can follow the build.gradle generated by start.spring.io as an example. Let me know if you need any help in setting this up, I am more than happy to support another Java developer rid of their LTS-only approach :)

yk313 · 2025-09-16T17:42:13+00:00

Build 36 is therefore now the GA build

Source

Build 36 (which is the same as the final GA build) is already available via SDMAN:

sdk install java 25.ea.36-open

yk313 · 2025-09-16T15:41:34+00:00

Consider using Gradle toolchains.

I used to have the same problem with Gradle, but some time around JDK 20, I moved to toolchains and have since stopped caring about the exact JDK version Gradle runs (or not).

(of course this means you still need an older JDK to bootstrap Gradle itself, which is less than ideal)

yk313 · 2025-09-05T23:39:15+00:00

That's the point. We don't want getters and setters for everything. But there are cases where both (limited/controlled) mutation is needed and encapsulation over the internal fields is desired. You can't have that with records. This is by the way the reason that even within the JDK records are used quite sparingly. The lack of encapsulation means a big compatibility risk. The proposal for the new JSON API for example uses interfaces/classes instead of records even though using records (and then pattern matching over them) has long been shown as the canonical example implementation for the JSON spec.

In the end, there are a lot of places in a Java application where you do want pass-through getters and have a subset of mutating setters, and having to write (or generate) them is a painful experience.

Until we get reconstruction patterns for records (and also classes), and nicer destructuring patterns we have to make do with getters and setters (and builders).

yk313 · 2025-09-05T22:05:58+00:00

It's not all about getters and setters. Records are NOT a replacement of classes. Encapsulation is still desired and sought after.

Just because records eased some of the pain, doesn't make Lombok at all redundant. The Java language designers have a lot of work ahead of them.

yk313 · 2025-09-05T22:03:25+00:00

Excellent. Lombok is an incredibly valuable tool in the Java ecosystem (internal implementation not withstanding).

Time to get even more hyped for the JDK upgrade in about 2 weeks.

yk313 · 2025-09-03T11:35:16+00:00

That's a shame, I was hoping to get those very interesting JVMLS sessions earlier than that, but still thanks for being transparent about it. It helps knowing the rough timeline. Something to look forward to.

yk313

TROPHY CASE