[javaone 2026] Evolving the Java Language: An Inside Perspective

Speaker: Brian Goetz

See the live blog table of contents


General

  • Need to balance teaching Java new tricks, but feeling like has been part of language all along
  • Like living on the Ship of Theseus

Anti patterns

  • Didn’t want to be like Perl and cram in features. It’s nice was taken over by Ruby and Python
  • Someone wants a feature and extrapolate from one data point. View is hyperlocalized and doesn’t fit cleanly into rest of language. Starts with presupposing a solution vs developing a deeper, shared understanding of the problem.
  • Heroes journey archetype. With language features, they don’t always return home victorious. Like marble maze game where many holes to fall into

Many bad ideas

  • Undeclared statement. Undelcare x would mean taking it out of scope. Presumably useful for writing thousand line methods was to reuse variable in the same scope.
  • Easy to dismiss an obviously bad idea
  • Other idea aren’t bad ideas for some language, but not a good choice for Java. Or might have been a good idea for Java in the past, but decisions since conflict with it.
  • Make parameters final by default – backward compatibility issues. Could do for new syntax like lambdas or pattern matching, but adds complexity to what developers need to learn about when variables are mutable. Would have to be language historian to know when added to know how behaves. Living with mistakes of the past

Complaints

  • “just do what languageX does”. Features live in the context of a language. For example, dynamic types fits in Python. Taking inspiration from other languages isn’t much of a shortcut.
  • Why do you have to reinvent everything. Needs to fit Java. Doesn’t look nailed onto the side.

Ideas

  • Ideas are not a scarce resource
  • Having the idea is a very small percentage of the work
  • “Genius is 1% inspiration and 99% perspiration” – Thomas Edison
  • Steve Jobs said it is a disease thinking the idea is 90% of the work.
  • Person with idea gets the credit so get married to idea.
  • First idea is never as good as you think it is
  • Value of first idea is that it gets you to the next idea. And so

Solutions vs problems

  • Problems are better than solutions
  • Ideas often come dressed as solutions. Feels helpful. Not just complaining, have an answer.
  • Need context
  • What new problems will it cause
  • Will benefit exceed cost
  • Have to reverse engineer problem from solution
  • Maybe don’t understand problem. But usually there is some problem.

Syntax

  • Amateurs discuss syntax.
  • Suck up all the oxygen in the room and start again in the room next door.
  • Subjective
  • Critically important
  • Avoid pitfalls like thinking people would consider the method reference :: to be like C++
  • Don’t want new features to stand out “because new” but then become old with bold features

Semantics

  • Thinking is hard
  • There are no writing problems, only thinking problems
  • Trying to write something down clearly tells you if you understand it
  • Interactions with existing features, new
  • Interactions with already complex features
  • Solid theoretical basis or ad hoc

Translation (to bytecode)

  • Most developers on’t think about, and shouldn’t have to, think about bytecode
  • Important part of design process.
  • Affects performance
  • Default methods – no easy way to implement so had to do it the hard way
  • Symbols matter. Anonymous classes and stable names. Could affect reflection, deserialization, etc. Need to decide if ok for name to change

Constraints

  • User perception – can’t ask too much of users. Building on things already in language makes this better. Using similar rules to other parts of the language keeps intuition.
  • Past decisions – existing code written with a set of assumptions. Backward compatibility. Code that already means something else is a constraint of a past decision. Breaking changes undermine investment in code and trust in Java. Also think about future changes so not making a change that will cause future compatibility problems. Language features must go together
  • Future decisions – what paths are closed in future by decision. Can’t use up degrees of semantic freedom because then no way to implement better ideas. For example, can’t use up all delimiters
  • Ecosystem and incentives – avoid dividing ecosystem into libraries that do things in the new/old way. Create incentives to write good code
  • Budget – ex: complexity

Get more out of concepts/features that exist

  • Records as tuples
  • Sealed classes as generalization of final classes
  • Virtual threads are a type of thread

Evolving

  • Pattern matching introduced a bit at a time
  • Simple so easier to get
  • Replaced existing idiom with more concise idiom so people like. Marketing
  • Flow based scoping

Summary

  • A program is a means to an end
  • Language design is like writing all possible programs simultaneously
  • Have to understand how a feature can be used or misused

My take

I enjoyed hearing about the “whys”. The marble maze analogy was fun. And the examples are great. It was nice getting a peek behind the curtain.

[javaone 2026] Building Agents with Spring AI and Amazon Bedrock

Speakers: Josh Long & James Ward

See the live blog table of contents


Repo: live coded at session

https://github.com/joshlong-attic/2026-03-18-javaone-bootiful-spring-boot-ai

General

  • Agent – call LLM in a loop and give it tools so it can do things.

Spring Intiailzr pulls

  • Spring MVC
  • vector database (for RAG)
  • Amazon Bedrock (embeddings for RAG)
  • Amazon Bedrock Converse (for chat)
  • Spring Boot Actuator
  • MCP client

Random stuff

  • UnzipAndOpen.java – made an alias to run quickly
  • Postgres – pgvector – postgres with vector support

My take

I wasn’t sure what to expect from this. I put it on my calendar thinking it was more like a hands on lab (I also prepared my hack session immediately after in that format). I was warned the day before that most “hack session” presenters did mostly speaking. I saw this a similar presentation at the NYJavaSIG, but different emphasis.\. So I came both to get a feel for how I want to handle mine and to see what the space was like [hack sessions are in a tent where we had lunch]. Also luckily I was warned the tent gets hot so I changed into shorts before my time in the tent. (While it was hot for lunch, it wasn’t as noticeable because less time)

[javaone 2026] Developing an Asynchronous Application with Virtual Threads and Structured Concurrency

Speakers: Jose Paumarrd & Ana-Maria Mihalceanu

See the live blog table of contents


Structured concurrency pattern. Note tasks end by autoclosable block complete

try (var scope - StructuredTaskScope.open()) {

  var subtask = scope.fork(lambda)

scope.join()

var result = subtask.get();

}

Scopes

  • A scope can spawn other scope
  • Closing the parent scope closes the child scopes

Lab

https://github.com/JosePaumard/2026_JavaOne-Loom-lab/blob/Step-00_Initial-application/JavaOne-Loom-Lab.md

My take

This feels like streams where it is going to take me a few tries to “get” it. Luckily, I have time since structured concurrency is still in preview. I did ask my question about ScopedValues being useful without structured concurrency. You can use them but you need a ScopedValue.where() call for each thread as far as I understand which is limited in usefulness.