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

Speaker: Andrew Gross

See the table of contents

---

General

• Vulnerability – flaw or weakness that could be exploited to violates the system’s security policy
• Design/Architecture – faulty assumptions, missing security mech
• Implementation – insecure programming practices
• Integration/test – config errors, vulnerability third party code
• Deployment/release – missing third party patches

Cost of vulnerabilities

• Remediation time/resources to fix/build/release
• Intermediate response – migration, detection, incident response
• Damage to reputation – PR, liability

Secure coding

• Design/Architecture – training, threat modeling, missuse cases
• Implementation – manual code review, static analysis
• Integration/Test – dependency checkers, static analysis, runtime tesitng, negative testing
• Deployment/release – vulnerability scanning, monitoring (ex: WAFs_, dependency patching, vulnerability remediation

Secure Coding Guidelines for Java SE doc

• Guidlines at: https://www.oracle.com/java/technologies/javase/seccodeguide.html
• covers – general guidelines and Java specific ones
• Not meant to be comprehensive or a tutorial
• Update as see problems, additional context, new security features like JEP 486 to disable the security manager
• Gave examples of Security third party code, injection/inclusion, take care interpreting untrusted code, input validation, serialization/deserialization, filter untrusted serialized data

News

• 2021 – remote code execution in log4j
• 2021 – Confluence OGNL injection
• 2022 – Cobalt Strike – simulator for red tools. Had XSS vulnerability. Client uses Swing so HTML could be rendered into UI.
• 2022- Text4Shell
• 2024: XZ Utils Backdoor. Malicious co-maintainer over several years. Was trying to put into httpd but discovered first
• 2025: npm packages compromise. phishing
• 2025 – deserialization – SAP NetWeaver, Cisco Unified Contact, NetIQ, SolarWinds, etc

Takeaways

• Apply secure coding practices to eliminate and minimize impact of vulnerabilities
• Consider security throughout the SDLC
• Follow the Secure Coding Guidelines for Java

My take

I didn’t realize how closely this was going to be of presenting the guidelines document. Which I’ve read. So the session itself was fine, but I should have chosen a different one. The from the news part was more engaging for me. I was also surprised not to have any AI mentions. It wasn’t in the abstract, but affects the SDLC