Contact

Email is the only channel, and it is read.

[email protected]

What gets a reply

• Corrections. A wrong claim, a broken code sample, a benchmark that does not reproduce. Include the JDK version and the command you ran, and the fix will be faster.
• Article suggestions. Especially the shape “I expected X, the runtime did Y, and I could not find a good explanation anywhere”.
• Questions about a published article. If the answer is long enough, it may become its own article — you will be told if so.
• Privacy requests. Anything under the GDPR: access, erasure, objection. See the privacy policy for what is actually held, which is very little.

What does not

Guest-post offers, link insertions, paid placements and “content partnerships” are declined without a reply. Nothing on this site is sponsored, and no article carries a link that was paid for.

Why email and nothing else

There is no comment section under the articles, and no social account to reply on. Both are deliberate.

A comment thread on a technical article tends to accumulate two things: corrections, which belong in the article itself rather than underneath it, and arguments that were settled elsewhere years ago. Moving corrections into the text means a reader arriving in two years gets the corrected version rather than a wrong paragraph with a right reply eleven comments down. Email makes that possible; a comment box makes it unlikely.

The absence of social accounts has a simpler reason. This site publishes an RSS feed, a plain-Markdown version of every article, and a llms.txt index for machine readers. Those are durable, portable and require nothing from you but a reader of your choosing. A social feed would add a channel that a platform controls and can withdraw.

Making a technical question answerable

A message that includes the following gets a useful answer instead of a request for more information:

• The JDK release and vendor. java -version output is ideal. Runtime behaviour is version-specific, and half the questions that arrive here have a different answer on JDK 21 than on JDK 24.
• The flags the process runs with, particularly the collector, the heap sizing, and anything under -XX.
• What you expected and what happened, stated as two separate things. The gap between them is usually where the interesting mechanism lives.
• A minimal reproduction, if one exists. It does not have to be small — it has to be runnable.

Questions about production behaviour that cannot be reproduced are still welcome. In that case, the useful attachments are a thread dump, a GC log segment, or a JFR recording, whichever matches the symptom.

Republishing and permissions

Quoting an article with attribution and a link needs no permission. Translating one, republishing it in full, or including it in a course or internal training material does — ask, and say where it will appear. Requests of that kind are usually granted, and the answer arrives faster than the licensing terms in the terms of use might suggest.

Code samples are exempt from all of this: take them and use them, no attribution required.

Reporting a problem with the site

Broken rendering, a code block that lost its formatting, a dead link, a page that fails to load on a particular browser — all worth reporting. Include the URL and, if it is a rendering issue, the browser and its version. The site is a static build with no client-side framework, so problems of this kind are rare and usually fixed the same day.

What happens to your message

Your email address and the content of your message are used to reply and for nothing else. They are not added to a mailing list, because there is no mailing list. Correspondence is deleted once the matter is closed. The full detail is in the privacy policy.

Response time

Usually a few days. A correction that affects a published article is handled first, and the article is updated in place with a revised date.