Daily Archives: March 18, 2025

[javaone 2025] stream gatherers: the architect’s cut

Posted on by
Reply

Speaker: Viktor Klang

See the table of contents for more posts

Oracle has sample code so I didn’t take notes on all the code

General

  • Reviewed source, intermediate operations, terminal operations vocabulary
  • Imagine if could have any intermediate Stream operations; can grow API
  • Features need (collectors don’t meet all needs) – consume/produce ratios, finite/infinite, stateful/stateless, frugal/greedy, sequential/parallelizable, whether to react to end of stream
  • Stream gatherers preview in Java 22/23. Released in Java 24

New interface

  • Gatherer<T, A, R> – R is what goes to next step
  • Supplier<A> initializer()
  • Integrator<A, T, R> integrator() – single abstract method boolean integrate(A state, T element, Downstream<R> downstream) – single abstract method – boolean push(R element)
  • BinaryOperator<A> combiner()
  • BIConsumer<A, Downstream<R>> finisher()

Basic Examples

  • Showed code to implemented map()
  • Gatherer.of() to create
  • Call as .gather(map(i -> I +1)
  • Other examples: mapMulti(), limit()

Named Gatherers

  • Progression – start as inline code and then refactor to be own class for reuse.

Parallel vs Sequential

  • For sequential, start with evaluate() and call in a loop while source.hasNext() and integrator.integrate() returns true
  • For parallel, recursively split the upstream until the chunks are small. (Split/fork into distinct parts)
  • For takeWhile(), need to deal with short circuiting/infinite streams. Can cancel() or propogate short circuit symbol

Other built in Gatherers

  • scan() – kind of like an incremental add/accumulator
  • windowFixed() – get immutable list of certain sized optionally keeping last
  • mapConcurrent() – specify maximum concurrency level

Other notes

  • Can compose
  • Stream pipeline – spliterator + Gatherer? + Collector

My take

This is the first time I’ve seen a presentation on this topic. It was great hearing the explanation and seeing a bunch of example. The font for the code was a little smaller than I’d like but I was able to make it out. Only a bit blurry. Most made sense. A few parts I’m going to need to absorb. He did say “it’s a bit tricky” so I don’t feel bad it wasn’t immediately obvious! The diagrams for parallel were helpful

[javaone 2025] A Java Developer’s Guide to Navigating the Frontend Landscape

Posted on by
Reply

Speaker: Dan Vega

See the table of contents for more posts

repo with examples: https://github.com/danvega/java-developer-frontend-landscape

General

  • “The front end changes a lot but so do we”

Java Frameworks

  • Web application frameworks – Spring MVC, Struts, etc.
  • Java template engine – Thymeleaf, JTE (java template engine – newer option), freemarker, Mustache (logicless; only substitute values) groovy templates
  • Component based UI frameworks – Vaadin (pure Java), JSF, Wicket (clear separation of markup and logic)
  • Hybrid – JHipster (development platform for Spring Boot with Angular/Refactor/Vue and microservices), Hills (from creators of Vaadin. Combines Spring Boot and react)
  • Desktop frameworks – JavaFX

HTML/CSS/JavaScript

  • package managers – npm (website, cli, registry), pnpm, yarn, jsr
  • nvm is like sdkman but for Node; let’s you have different versions
  • build tools – webpack, parcel, rollup.js, esbuild (fast tool to create bundles; written in .go), vite
  • runtimes – nodejs, dino (creator of node; wanted to start fresh), bun (all in one tool – runtime, package manager, build tool)
  • htmlx – like the new jquery. Attach attribute to HTML.. Ex: hx-post, hx-trigger, hx-target, hx-swap

JavaScript Frameworks

  • React, Angular, Vue
  • Can update DOM quickly, hold state, best for single page applications, interactive dashboards, real time applications

Consider when choosing

  • Team skillset
  • Solo dev vs team
  • Greenfield vs existing project
  • Architecture needs of project
  • Back office vs customer facing
  • Whether SEO is important
  • Whether needs to look good

My take

Great overview/comparison of the many choices out there and their features. It’s great it came with a sample repo to reference. The demos were good too for seeing some of them running.

[javaone 2025] interested in where the language is going

Posted on by
Reply

Speaker: Brian Goetz

See the table of contents for more posts

Note: I was 15 minutes late to this session as I was doing a book signing:

Patterns

  • like expressions turned inside out
  • data flows from the environment into the expression
  • If expression succeeds, produces a result
  • Patterns compose like expressions
  • Payoff is that Java is better at dealing with Java
  • OOPs strong suit (complex entities/boundaries) became less important. Data has become more important
  • Pattern matching allows us to sometimes recover lost details – ex: type
  • Eventually can decompose any class, not just records.
  • Will impact API design
  • Lots of work left. Started with features that are easiest to understand.
  • Will use for marshalling in future

Valhalla

  • Goal is flatter and denser memory layouts for Java object graphs, unify the type system (primitives vs objects), enabling new numeric types as libraries rather than new primitives
  • Big refactoring
  • While JVM doesn’t specify object layout in memory, have to use pointers
  • Locked into existing layout – objects have identity so can only have one copy, references re nullable so need certain number of bits, kept discovering more
  • Primitives were necessary in 1995 for performance bug has dogged us ever since. Like original sin.
  • Rift widened in Java 5 with generics and then again in Java 8 with lambdas
  • Primitives are a performance hack for flatness and density
    • JEP 401 – value classes – not all objects need identity . If don’t need, JVM has more flexibility and can store however wants. Implicitly final. == uses state not identity. No intrinsic monitor.
    • Use as few degrees of freedom as possible. Favor private over public. Favor final over mutable. Favor value over identity
    • Flattening should be a JVM optimization. Language model should be about program semantics. Give up things that are impediments to flattening.
    • Nullability is a density and flatness hazard. Also a safety hazard. Not all code wants/needs nullability; place for bugs to hide
    • Future JEPS – null restricted types, null restricted value types, minimize gaps between int and Integer and surely more

My take

It was nice hearing about these features from Brian’s POV. While I didn’t learn much about the features, I did learn a bunch about the philosophy which was interesting. Also that was intentional since I knew I’d be late. I needed something I could jump into without it being cumulative. This fit the bill!