Java With Us

Editorial policy & methodology

How content on Java With Us is researched, written, reviewed and kept current.

This page documents how articles on Java With Us are produced, what we commit to our readers, and how mistakes get corrected. It exists because we want the site to be judged on something more concrete than marketing copy — here is how the sausage is actually made.

The editorial team

Java With Us is produced by a small editorial team of professional Java developers. The editorial lead is Daniel Whitaker, a Bay Area software engineer who has been writing Java since the 1.0 release in January 1996 — 30 years in the language across financial back-ends, early Android, the Spring and Hibernate era, and the modern Spring Boot / JVM ecosystem. Daniel reviews every published piece and maintains the site's style guide. Additional contributors are subject-matter reviewers drawn from working developers — they are credited on articles they've reviewed when their employer's policy allows.

What we cover (and don't)

We cover: the Java language (syntax, features up to Java 25), the JVM (installation, tuning, garbage collection), common errors and exceptions, the standard library, the most-used frameworks (Spring Boot, JPA/Hibernate, Jakarta EE at a high level), build tools (Maven, Gradle), and the day-to-day developer tools that surround Java work.

We do not cover: short-lived Java library tutorials that go stale in six months, framework-specific deep-dives that are better served by the vendor's own docs, and anything where we cannot meaningfully add to what is already well-documented elsewhere.

How each article is produced

  1. Topic selection — driven by real search queries, reader questions, and gaps we see in existing online documentation. We prioritise questions that do not already have a good answer on the open web.
  2. Research — we consult the primary sources first: Oracle documentation, the Java Language Specification, relevant JEPs, the OpenJDK source when needed. We run every code example against a real JDK (Temurin 21 by default) before publishing.
  3. First draft — written by the assigned author in Markdown, with all code samples tested in a Java Online Compiler or a local sandbox.
  4. Editorial review — Daniel reviews every draft for technical accuracy, clarity, and alignment with the site's style guide (no fluff, working code, modern Java first).
  5. Subject review (when relevant) — deep or contentious topics (concurrency, security, performance) get a second pair of eyes from a developer with specific experience.
  6. Publication — the article ships with a published date and is added to the sitemap, FTS search index, and relevant category hubs.
  7. Ongoing maintenance — see maintenance below.

Primary sources we use

  • Oracle Java Documentation — docs.oracle.com/en/java/javase for the official API reference, tutorials and installation guides.
  • Java Enhancement Proposals (JEPs) — openjdk.org/jeps for the design rationale of every language and JVM feature since Java 9.
  • Java Language Specification (JLS) — the authoritative reference for language semantics. We cite JLS sections when a claim is subtle.
  • JDK vendor documentation — Adoptium Temurin, Amazon Corretto, Microsoft Build of OpenJDK, Azul Zulu — for installer specifics, supported platforms, licensing.
  • OpenJDK source and mailing lists — github.com/openjdk/jdk for implementation details and the bug database.
  • W3C / IETF RFCs for protocol questions (HTTP, WebSocket, JWT).

Secondary sources (blog posts, Stack Overflow, framework docs) are used as starting points but never as the final authority — if a fact cannot be traced back to a primary source, it does not get stated as fact.

Style and structure commitments

  • Get to the point. No "in this article you will learn" intros, no recap conclusions.
  • Working code. Every snippet compiles and runs against the stated Java version. External libraries are explicitly named.
  • Modern idioms first. We target Java 17 and 21 LTS by default. Where the old idiom is still common, it is shown alongside the modern version.
  • One topic, one page. No artificially split multi-part tutorials to inflate page counts.
  • Internal linking. Related terms link to their glossary entry; related concepts link to their learn pillar.

Ongoing maintenance & updates

Articles on Java With Us are not "publish and forget". We review and update content under three triggers:

  1. New Java LTS release — when a new LTS (21, 25, next) ships, we sweep the FAQ, installation guides and glossary for version references to update.
  2. Reader-reported errors — errors flagged via the contact page or spotted internally. Corrections are typically made within a few days.
  3. Feature deprecation or removal — when a Java feature is deprecated (e.g. Security Manager in 17, removed in 24) or a tool/library recommended in an article is discontinued, we rewrite the affected content.

Each article displays its last-updated date at the top. When a substantive change is made (not a typo fix), we note what changed and why at the bottom.

Corrections policy

If you find a factual error, a broken code example, or out-of-date information:

  1. Send a note via the contact page with the URL of the article and what you believe is wrong.
  2. We verify against the primary sources listed above.
  3. If the error is confirmed, we fix the article and acknowledge the correction in the update note. You can request to be credited (first name, or anonymous — your call).
  4. If we disagree with the report, we respond explaining why. Technical disagreement is always welcome — several articles have been improved by back-and-forth with readers.

Use of AI tools

We use AI coding assistants (GitHub Copilot, Claude) the same way a working developer does: for drafting code examples, catching typos, and spotting missing cross-links. We do not publish AI-generated text as-is. Every article is written or rewritten by a human, with AI-suggested content edited substantially, fact-checked against primary sources, and reviewed before publication. When we do use AI assistance in a material way — for example, to suggest the initial structure of a long technical page — we are open about that process but we take full editorial responsibility for what ends up on the page.

Funding & disclosure

Java With Us is supported by:

  • Display advertising — Google AdSense contextual ads. Ads are clearly labelled, never placed inside code blocks, and never disguised as content.
  • Reader donations — when available. No recurring subscription model.

What we don't do:

  • No paid placement. When we recommend a specific JDK distribution, library or tool, it is because we use it or have documented reasons to prefer it.
  • No affiliate trickery. If a link is ever an affiliate link (we don't currently have any), it will be labelled.
  • No sponsored articles disguised as editorial. If we ever publish genuinely sponsored content, it will be labelled "Sponsored" at the top of the page.

Privacy & data

See the full Privacy policy for what data is collected and how it is used. Short version: cookies are used for AdSense personalisation (with consent), basic analytics, and nothing else. We do not sell reader data.

Feedback

This editorial policy is itself open to feedback. If you think something is missing, unclear, or inconsistent with what you actually see on the site, tell us. The policy evolves.