Show HN: I Wrote a Book on Java

Hacker News Discussion ↗

A new Manning book on “data-oriented programming” in modern Java has prompted debate over how best to model data using features like records, pattern matching and algebraic data types. Commenters contrast the book’s strongly typed, immutable approach with Clojure-style untyped maps, and explore challenges such as type proliferation, builders, optional fields, and working within ORM- and entity-centric ecosystems. The thread also touches on Java’s evolving feature set and licensing, how it compares to languages like Kotlin, Python and TypeScript, and the realities of writing and maintaining technical books while key language features remain in preview.

Overall reception & early access model

  • Many commenters congratulate the author and express interest; several say they bought the early-access ebook or plan to when finished.
  • Some prefer to “wait until it’s done” and note the Spring 2025 target; others like the iterative access model.
  • One reader reports checkout / login issues with the publisher’s site.
  • A minority reaction: one buyer felt the book is verbose “lingo bingo” that could be condensed heavily.

Data-Oriented Programming (DoP) vs OOP

  • Thread revolves around DoP in Java, influenced by Clojure / FP ideas, but still “letting Java be Java.”
  • Author’s approach: immutable, strongly-typed data (records, algebraic data types), leveraging the type system to make invalid states unrepresentable.
  • This explicitly contrasts with another “data-oriented” book that uses immutable but untyped maps.
  • Some see DoP as a natural outcome of functional and “evolutionary” architecture; others warn about complexity and type explosion.

Typing, records, and invariants

  • Java records are discussed heavily: they’re immutable (fields final) but can hold references to mutable objects.
  • Concern: public canonical constructors make it harder to force construction via builders / factories.
  • Counterpoints:
    • You can validate invariants in the canonical constructor body (non-null, ranges, transformations).
    • You can encapsulate records behind interfaces or module boundaries, or use dedicated value types (e.g., validated date wrappers).
  • Withers, builders (including Lombok), and named-parameter-like patterns are suggested to tame telescoping constructors.

Type proliferation, optionals, and domain modeling

  • Some worry about an “explosion” of slightly different aggregate types (e.g., many Car variants with different fields).
  • Proposed strategies:
    • Use Optional fields instead of many distinct types, accepting that consumers must handle absence.
    • Introduce separate DTOs or “creation” types where domains are stable; be more lax where domains are evolving.
    • Accept that only a small subset of theoretically possible combinations matters in real domains.
  • Debate over trade-offs: explicit types vs development speed, and when in a project’s lifecycle to favor each.

Comparisons to other languages & ecosystems

  • Python: numerous comments about using dicts/lists vs dataclasses/TypedDict/pydantic; static typing is possible but not central to the ecosystem.
  • TypeScript: praised for type arithmetic (e.g., Partial, Omit) and structural typing; some wish Java had similar tools.
  • F#, Clojure, Haskell, Idris, Elixir are cited as prior art for DoP / ADTs / typed data modeling.

Modern Java, previews, and licensing perceptions

  • Several comments note how far Java has come (records, pattern matching, text blocks, Loom, ADTs, ZGC).
  • Concerns about “preview” features possibly being withdrawn; author says book stays tool-agnostic and offers fallbacks for older JDKs.
  • Some see Java’s cautious process as slow but desirable; others compare it unfavorably to Python’s pace.
  • Java licensing confusion is discussed: consensus is that OpenJDK and non‑Oracle builds remain freely usable and popular; FUD is called out.