See the table of contents

---

Notes

• Types of features: language, JVM, library
• Structured concurrency – getting close. A few tweaks remained so went with another preview. Seventh preview is Java 27. Re-previewed without changes at first and then all the changes occurred together. Similarly with HTTP client. People don’t always pay attention at first. Feedback is not “why don’t you do it another way”. it’s “I tried it and x”. Just because preview doesn’t mean not production ready.
• Project Babylon – “It’ll be ready when it is ready” Flow: submitted, candidate, target. Want to get code to be incubated. Use cases are incredibly broad. Need community to try it in a range of use cases and report back on how went.
• Infinite number of things could work on and finite resources so prioritization problem. Some things only JDK can do and some things can be done by a library. The JDK only ones are higher priority because nobody else can do them. Also look at other languages to see if gaps.
• Need to decide what libraries should be included. “Batteries included” like XML and JSON support. Virtual threads output format is JSON. Configuring the JDK through property files is out of the 90s. Adding JSON config would be great which motivates adding JSON parsing to the JDK. Won’t be as full featured as a full parsing library, but core library to have some support.
• Don’t grab a library from outside and dump it in the JDK. Tried several times and get burned by it followed by an expensive process to remove. Maintained on own schedule/priorities. Recipe for stagnation.
• A feature being added should make existing features stronger, not make them look bad. Such as lambdas which made interfaces stronger.
• Module system not loved. Build tool support issue; similarly for starting an agent. So people use libraries instead of agents. Also benefits of modules, not enticing enough as they stand right now. Story of modules not over. Useful building block and lots of new features can add on top of them. JDK itself was modularized A lot of libraries didn’t modularized. Dream was people would jlink their application and use that in their docker container. Framework with pakcages in different jars has to redesign itself. And if library doesn’t modularize, not useful for apps to do. Spring did modularize.
• java.lang.unsafe is still available. JDK internal packages not available.
• Performance of streaming API. Hand specialized streams like IntStream, LongString. Not a sustainable approach. Started down path to Valhalla. Stream API is for expressing code clearly. Customize most performance critical loops.
• Want API to encourage writing code that makes sense to humans and also makes for good machine code. Sometimes these conflict. Sometimes leads to pattern of a bunch of setup and then press the big red button.
• People running library choose how – ex: classpath, modified JVM. Can’t solve problems by getting rid of the classpath. People are very attached. When lock something down, people come with pitchforks. With this pitchfork for not locking things down.
• Lombok is trying to solved a reasonable problem. Lombok is ill behaved in hacking into unspecified interfaces and changing ASTs used by compiler. Largely solving yesterdays problem like mutable JavaBeans which have discouraged for a long time. When generate Java code with lombok, have to de-lombok it.
• Header size shrunk from 12 to 8 bytes. Should be memory depending on fragmentation. Need to try and measure to see how works.
• Go has own build tools that control. This isn’t something only the language creators can do. Recognize as problem and consider a high priority. Very few people maintain the Maven core/plugins.
• Pet projects – I like the one about generating hash codes
• The question isn’t can AI help; it’s how can it best help. People experiment as pet projects and management led projects.
• Open source projects suffering from drive by PRs with AI agents running around leaving. Open JDK setup in way that makes it harder. Be careful if AI generates code and unit tests; need to make sure they are legit and not sabotaged unit tests that “pass”. Still need to look over AIs shoulder and sometimes take the wheel. Maybe next year behavior will be different.
• Amdhal’s law – If you can speed up one part of a serial process, limited in total speed up of remaining time.
• All about backward compatibility. Not going to redesign and start over. What is so good that is worth sacrificing. If so good, multi step migration path.
• In most cases, kids aren’t picking the first language; their teachers are. Biggest impediment is perception comparing Python of today to Java of 15 years ago. Need more awareness of new features. Harder to reach educators than developers

Humor:

• “do you have any thoughts”
• “we have lots of thoughts”
• ‘ideas are cheap I heard”

My take

Great end to the conference! People asked good questions so it was interesting and fun. It paired nicely with Brian’s keynote yesterday which was more philosophical and this gave an opportunity to go deeper. And got to have back references to John’s session immediately before. Really enjoyed the perspectives and insights.

Speaker: John Rose

See the table of contents

---

Deck: https://cr.openjdk.org/~jrose/pres/2026-0319-SpecializedGeneric.pdf

(encouraged to follow along on own device because goes fast/info dense)

C++ vs Java

• Both C++ templates and Java generics write well tuned ocde handling mainy times and give good performance (on a good day)
• Java’s are dynamic where C++ specialized code for each case at complier time. Java generic can operate on types unknown at compile time.

Performance

• Java hand tuned code equivalent to C++ templates
• For some reason reflection is faster in some cases
• Was fast due to profiling, de-virtualized (knowing type), inlining code.

Boxing

• Overhead – pointer -> Header + payload
• primitives don’t mix well with generics yet
• Valhalla will make any value class flattenable reducing array access costs
• Flatter is faster and arrays typically stick to one type

Monomorphic

• Only one type/form
• Native machine code
• Looks static even though written dynamically for the JVM
• Even if became monmorphic after running a long time

Bimorphic profiles

• JVM struggles to optimize two types at the same time

Megamorphic

• Falls apart when three types
• Real code could have lots of types
• Performance cliff
• More dynamic stuff requires more static stuff
• Megamorphic code is two to five times slower than monomorphic code

Open questions

• How far can go transparently?
• Do we need new language features to improve performance?

Experiment – Hidden class

• Clone a class file into a hidden class and call the cloned methods.
• A hidden class isn’t in any specific namespace.
• Can be docked into a namespace and call private methods

Future

• Parametric JVM with Valhalla

Note

• C.A.R (Tony) Hoare was the inventor of QuickSort. He passed away this month.

My take

Glad he shared the slides. It’s helpful to be able to scroll and compare some of the performance numbers. Also some slides had a lot so easier to read right in front of me. This was very interesting. I enjoyed the deep dive. The numbers were interesting and the bytecode was interesting. I do wish this was earlier in the day as my brain is pretty full and there’s a lot of info here. The soup analogy was fun and helpful!

Speaker: James Ward

See the table of contents

---

General

• LLMs are knowledgeable translators
• Agents are LLMs with integrations in a loop. Continue until achieve users goal or give up.

Travel

• Pitch “The AI can book your travel for you”
• Not there yet.
• [personally, I’m not ready to give AI my finances. Also, I like tp pick my flight, not outsource that. I didn’t even have a human admin assistant book mine in the past]

Inference API

Using AWS Converse

• Text > LLM > Text
• Lext > LLM > JSON > Object
• Text > LLM > Stream
• Text + Text > LLM
• Text _ Image > LLM > Te/xt
• Image > LLM > Text

System promps

• extra information
• goal
• like an additional message

Integrations/tool calling

• ex: a clock to see the time
• Flow: send message and list of tools the LLM can use. LLM takes result from tool and has enough to formulate response
• Most models support tool calling; older ones didn’t always.
• Can set default tools or tools by call
• http://www.javadocs.dev/mcp for MCP and https://www.javadocs.dev for UI. Can get latest version, Javadoc
• Challenge: by default on load gets all tool metadata from all MCP servers which wastes tokens. Also hard to figure out which tool use if overlapping descriptions.
• Can deal with using semantic search across tooos, tool groups (idea from Embabel) so agent sees subset of tools that it can use, Embabel Unfolding tools

Skills

• Markdown file with sections for pieces of data
• Can selectively load as needed

Reusable skills

• https://skills.sh
• https://www.skillsjars.com

Memory

• LLM is stateless
• Memory provides means to keep track of messages such as database or hosted services like Amazon Bedrock Agent Core
• Short term – ex: message windowing. Keeping track of all messages doesn’t capture all nuggets like name in long run
• Long term – ex: LLM Compaction/Extraction

My take

This session was right after lunch and in a dark room. Super glad that James presents with a lot of energy making it easy to pay attention. Code was lcear and made it easy to understand the APIs. It was sufficiently different than the Hack Haus session which I appreciate