AWS Summit 2026

This was my second time attending AWS Summit NYC. Last time was in 2024. Like last time I didn’t live blog; it’s not set up well for that. So after the fact summary.

Overview

Like last time, AWS spent a ton of money on this event. They rented out all or most of the Javits Center in NYC (this is where NYC Comic Con is held). They gave coffee/soft drinks and even free lunch. And Dynatrace gave out ice cream.

The event app was great. It gave directions on a map within the building. The directions on the expo floor were particular helpful. (I’m familiar with the real rooms at Javits.

I was pleased with how they did security. They had everyone put their bags through an xray and walk through the advanced detectors they have at Broadway shows and ComiCon. Those go off for laptops and my glasscase. A lot of people had laptops so having all bags go through the xray rather than waiting for people to beep was much smoother. And they were fast weith the xray!

Expo/Keynote

The exhibit hall was large on the third floor with lots of vendors related to cloud. Lots of space and time for networking. They live stream the keynote to the expo stages (where you can listen with headphones or on speakers) and a big screen near the lunch area. The free ticket didn’t come with access to attend the keynote in person but it was nice to be able to wander and listen.

I attended 4 sessions on the smaller stages in the expo. Two had speakers so you could easily hear so I didn’t use the headphones for that. Good if you can’t filter out background noise though. The other two were on a stage without a speaker. The first one I could hear the speaker without headphones (lots of background noise to filter out so most people wore them). The second the speaker didn’t project as much so I didn’t hear him without the headphones.

Chalk talks

There were lots of one hour breakout sessions on the first floor. I went to two “chalk talks” which are supposed to be for experienced people and very technical. They have a whiteboard setup and a screen that projects the whiteboard. Last time I went they used it. The two I went to this time just used a prepared presentation and recorded demo. So like a regular session with more audience questions. Also one session I wanted to go to filled up before I got there.

Hands on sessions

I didn’t go to the hands on sessions this time. Partly because I didn’t want to bring my laptop (i was going to an event after where that would have been hard to watch). And partly from the schedule of what I wanted to see.

My notes

Ok enough about logistics. On to content.

Chalk talk – Improving constituent support with AI agents

  • Solves problem have having to read and analyze (long) docs
  • IDP = intelligent document processing
  • Have multiple agents with expertise in each part
  • Have orchestrator aggregate the finding and present in consolidated view
  • “If it can be done in code, it should be done in code” – re orchestrator doesn’t have to be AI, an be code (presumably written by AI)
  • Showed AI code review of AI code
  • “If Opus can’t read a it; I probably can’t either” – re a diagram’
  • My take: good first session. Even though it wasn’t what I expected in a chalk talk it was detailed and covered a bunch.

Beyond the token: The new economics of scaling enterprise agentic AI

  • “sanbox paralysis” – getting past POCs
  • MAS = multi agent systems
  • “Book of Agents as a Service” – architecture
  • SDLC – AIDLC
  • Maturity model: Opportunity diagnosis (identify high value business bottleneck), implementation, run/scale (prod fleet of agents), transformation (agent first model), orchestrating (MAS)
  • Key: oversight, smart delegation of subtasks, minimize human in loop (phase out over time)
  • New world of risk – prompt injection is now a functional catastrophe and not just a security vulnerability
  • Guardrails need guardrails
  • A2I – amazon augmented ai
  • Matruity jump when lose tolerance for black box/shadow IT. Code can’t just live on dev machine
  • Pricing models: user based (humans), usage based (tokens), KPI based (milestones – ex: claims processed, code deployed, tickets resolved”
  • Model: agents consume from a centarlized license pool and get charged for active reasoning cycles
  • Watch out for agent sprawl. Escape velocity is when you become dependent on a tool even if doesn’t meet guardrails.
  • Reasoning abundance vs token deflation (tokens cost less but costs more from doing more, loops, etc.
  • Right size model – intelligence overkill is a major cost driver
  • My take: Very good session. He covered a lot in half an hour. Very full session; could have used a room and not just been on the show floor

Chalk talk – Building Serverless apps with S3 Vectors

  • Amazon S vectors as easy as S3 to use
  • Subsecond performance
  • Scale to billions of vectors
  • All attributes of S3 like durability
  • Previewed a year ago at AWS summit and GA’d at reinvent
  • UP to 10K similarity results per query
  • Can query with CLI, SDK or AWS Console
  • Billing – pay as you go based on PUT requests, compute, storage, and queries
  • My take: This was not the talk I picked out (that talk was full when I got there. This one was interesting though so I’m glad it was nearby. I did have to leave this one earlier because it started 15 minutes after the session I planned for.

CI/CD meets agentic AI (from GitLab)

  • 21% of time is writing new code
  • 74% of devs want to consolidate their toolchain
  • Demo of DUO (DAP – duo agent platform)
  • Can fix pipeline failures (by pressing button or automatically with agent).
  • Reads logs and repo for context
  • Fixes problem and opens MR for a human to review
  • The recorded demo was of a bad commit to a readme and the fix.
  • After the prepared presentation was done, the speaker asked if we wanted to see a bonus demo of a custom agent. That was live. She injected some problems in code and showed them being detected like a missing paren, logic error and security issue.
  • My take: Recoding the demo made sense because there were some waits that the demo could skip. She commented on them; one step was 11 a time jump.This was a very good session. The speaker was awesome. Great energy and clear. She was also so excited to share the bonus demo and we were excited to see it.

GitLab Duo Agent Platforrm with Amazon Kiro

  • Live demo of Duo. Some similar to the previous one so not rewriting everything.
  • Emphasis on coding is a small part and writing code is not bottleneck.
  • Much time spent on other things like testing.
  • Showed AI determining which items in vulnerability report likely false positives
  • “Most enterprises want a human in the loop”
  • Token is about 1.3 words
  • Orbit – semantic knowledge graph. Stores alongside metadata. Let’s query index.
  • Can query MRs; not just code
  • Can tag agnet in MR comment to interact and create traceable discussions
  • Kiro – compared to claude code, codex. IDE for spec driven dev – I have idea > help me write requirements > help decompose tasks > code tasks
  • My take: I liked the previous session better. I still learned stuff in this one, but I thought it would cover more about Kiro. I asked before the session started and was told this one would cover Kiro. And Kiro was in the name. The speaker mentioned Kiro at most once until the Q&A when I specifically asked about it.

Getting started with Generative AI

  • The beginning of this was introductory which makes sense given the title . I wanted to see what concepts AWS considered important for people to know
  • AI is about probabilistic results. Google maps did that for years before AI with driving estimates.
  • Estimates are ok for some tasks like driving directions and not ok for others like when wheels on plane will touch down if you are a pilot/air traffic control.
  • “Not magical; just another tool”. I had a problem with this analogy because he repeatedly compared gen AI to a calculator. Yes they are both tools. But my *calculator* gives deterministic results.
  • Another analogy that didn’t land was that he said understanding AI is like driving. Can live without knowing it, but…. [I live in NYC and haven’t driven in about 20 years. I get his point that gen AI is important but not a fan of the analogy/
  • Key skills for business leaders: fairness (is solution fair), explanability (what do you want), privacy and security (protect data and models), safety (harmful output), controllability AI behavior), veracity, governance, transparency (ex: does user know talking to a chatbot)
  • Key skills for devs: prompt engineering (compared to talking in a meeeting where things went wrong), RAG, agentic systems, model customization (fine tuning, domain specific data, examples)
  • Kiro.dev – go from AI coding to engineering. Helps create apps using agents. Free tier.
  • Amazon quick – for non coders to automate tasks

[javaone 2026] ask the java architects

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.

[javaone 2026] How the JVM Optimizes Generic Code – A Deep Dive

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!