Tag Archives: spring

[devnexus 2026] it’s up to java developers to fix enterprise ai

Posted on by
Reply

Speaker: Rod Johnson (@springrod)

See the DevNexus live blog table of contents for more posts

General

  • Personal assistant approaches don’t work in the enterprise
  • Hype can be distracting
  • AI conversation driven by people not interested in/don’t understand the enterprise
  • Some things work; some don’t.
  • Change is fast. ex: Clause over last 6 months

Personal assistants

  • Personal assistants use cases work best
  • Coding assistants are a type of personal assistant
  • Valuable because you are at computer and say yes/no
  • This doesn’t walk in enterprise. Business process/chatbot with public can’t do take backs
  • Broad, flexible, human in the loop, tolerance for error, chat oriented. (By contrast business processes need to be specific, predictable, automated, reliable, workflow oriented)

Claude Code Execution Process

  • Analyze Request
  • Create to do list
  • Work through tasks
  • Test each step
  • Ensure integration

Unavoidable Challenges

  • Non deterministic
  • Hallucinations
  • Prompt engineering is alchemy. Throw things in vs engineering
  • Slow and expensive to run at scale
  • Difficult to test and validate

Avoidable Challenges

  • Top down mandates
  • “AI all the things”/AI for the sake of AI – should be doing incrementally
  • Wrong people controlling AI strategy. Data science group doesn’t always understand the business
  • Greenfield fallacy – business systems/workflows already exist. Domain context exists.
  • “This time is different” – no matter how shiny a new technology is; doesn’t change everything.

Instructive Open Claw Problems

  • Lack of structure – relies on markdown.
  • Token bloat and very high cost
  • Needs to compress context frequently which can change meaning/introduce risk of errors
  • Unpredictable especially as context grows
  • Lack of explainability
  • Exposed infrastructure risk article – egads. This is scary!

How to succeed

  • Attack non determinism – make as predictable as possible by breaking complex tasks into small steps; smaller prompts, less tools in context, mix code in for some steps, create guardrails, (Also saves money because some steps can use a cheaper LLM)
  • Integrate with what works – connect to existing system, leverage current domain expertise/coding skills, build on proven infrastructure, incremental
  • Build structure to LLM Interactions – don’t talk English if can avoid; include as much structure as possible. Ask for format of structured data.

Testing

  • Unit testing can find that you sent the wrong prompt (or implemented wrong)
  • Integration testing – test with real LLM but fake data – ex: test containers

Domain Integrated Context Engineering (DICE)

  • Context engineering more broad than prompt engineering
  • Bridges LLM/business system
  • Helps structure input and output
  • Domain objects
  • Integrate with existing domain models
  • Structure is a continuum from Open Claw (autonomous/unstructured) to old fashioned code. In between is Claude, MCP, agent frameworks and deterministic planning.
  • Embabel is the agent framework/deterministic planning level

What do as Java developers

  • Gen AI works best alongside existing systems
  • Your data/domain models/business rules
  • AI should extend your capabilities not replace them.
  • Think integration, not greenfield
  • Java skills undervalued to this point
  • Every Java developer should know both Java and Python [I do; yay]

Python vs Java

  • Don’t just imitate Python approaches
  • Build better – look at prior art (Python), leverage domain experience, apply architecture experience, bring strengths to Gen AI, create better frameworks, lead
  • Python – great for data science (data science != gen ai), scripting, prototyping
  • JVM – excels at enterprise grade applications

Embabel

  • Directly addresses key Gen AI failure points
  • Key innovation is deterministic planning [Python frameworks do not do this]
  • Goal Oriented Action Planning (GOAP)
  • Predictable/explainable execution
  • Actions and goals create extensible system
  • Includes a server; knows what up to.
  • Knows about all deployed capabilities and can extend
  • Builds up understanding of domain
  • Will become AI fabric of enterprise
  • Framework written in Kotlin; put a lot of effort into making sure easy to use from Java.
  • Most examples in Java and most of users/community are Java
  • Builds on existing stack.

Unfolding Tools

  • While better to have samller steps with less tools, sometimes you need a lot of tools
  • Tools use a lot of context and can confuse the LLM
  • Unfolding saves tokens and improves accuracy
  • Exposes a single top level tools. When invoked it expands to show children. Like Russian nesting dolls
  • Works by rewriting message history within agentic loop

Agentic Tools

  • Like supervisor pattern in Python framework, but more deterministic
  • Eposes single top level tool that coordinates lower level tools
  • Advanced implementations allow controlling order

RAG

  • Currently pipeline RAG. Do query , no feedback, hard to adjust
  • Future is agentic RAG – context aware multi step search with self-correction. LLM has more autonomy. Can do more searches: text, vector, expand chucks, etc

Rod wrote blog post: You can build better AI Agents in Java than Python

My take

After hearing about one shotting and exaggerations on social media, having a more balanced take was great. I especially appreciated the *whys*. I also liked the “what can you do” to use AI more safety problem.

[2022 javaone] foundations of modern java server apps

Posted on by
Reply

Speaker: Kito Mann

For more see the table of contents

Notes

  • In cloud, have both microservices and traditional web apps

Microservice

  • Container (ex: docker) including UNIX kernel
  • Executable Jar or Native Image (ex: Graal)
  • Example microservice framework – Http Server, Http Java Integration, REST processing, JSON serialization, JSON parsing, validation, security, database integration, dependency injection, messaging, mail, health checks, tracing, fault tolerance, metrics, config, OpenAPI docs, GraphQL
  • Microservice frameworks – Spring boot, quarkus, micronaut, open liberty

Spring Boot

  • Http Server – Jetty, Tomcat or Underflow
  • Http Java Integration – Jakarta Servlet
  • REST processing – Jakarta RESTful Web Services or Spring MVC
  • JSON serialization – Gson, Jackson or JSON Binding
  • JSON parsing – Gson, Jackson or JSON Parsing
  • validation – Jakarta Bean validation
  • security – Spring security
  • database integration – JPA and others
  • dependency injection – Spring framework
  • messaging – Jakarta messaging, kafka and others
  • mail – spring java mail sender or jarkarta mail
  • health checks – spring boot actuator
  • tracing – spring cloud sleuth
  • fault tolerance – spring cloud circuit breaker and spring cloud netflix
  • metrics – micrometer
  • config – spring boot config
  • OpenAPI docs – Spring REST data
  • GraphQL – Spring for GraphQL

Others

Did same for Quarkus, Payara Micro, Jarkarta EE. Didn’t transcribe deck

A lot of delegating to Jakarta and MicroProfile projects

MicroProfile

  • Started in 2016

Jakarta projects

  • Jakarta Interceptors – standard way of writing interceptors
  • Platform – Jakarta enterprise beans, authorization, batch, connectors, mail, activation, messaging, web profile, core profile
  • Optional (not fully supported) – Jakarta enterprise web services, xml binding, SOAP with attachments, XML web services
  • Web profile – servlet, bean validator, persistence, authentication, web socket, CDI, mail, security, transactions, expression language, managed beans, concurrency, faces, standard tag libraries, server pages, enterprise beans light
  • Core profile – interceptor, dependency injection, annotations
  • Required for MicroProfile – Jakarta RESTful web services, JSON processing, JSON binding, CDI light
  • CDI surpassing EJB
  • New: Jakarta RPC, NoSQL, data
  • Removed: Jakarta Management

Java EE Server

  • War
  • Jakarta Servlet, RESTful web services, JSON binding/parsing, bean validation, security, persistence, CDI, messaging, mail

My take

Wow. A lot has changed since I last worked on a web app. Learned a lot here although the talk was longer than my attention span; especially later in the day. It was a bit of an info dump but good for getting the lay of the land. And I need to do a lot of reading!

[kcdc 2022] diving into debugging spring boot applications

Posted on by
Reply

Speaker Mark Heckler @mkheck

For more, see the table of contents

Notes

  • Developers don’t believe in magic
  • Most developers are bad at debugging. Or at least not as good as they could be
  • We got sloppy when we get used to thinking we know what’s happening
  • Important to isolate problem and not just symptoms

Code wakthru

  • @SpringBootApplication – meta-annotation. Enables the other scaning annotations
    • @SpringBootConfiguration
    • @EnableAutoConfiguration
    • @ComponentScan
  • Starter parent pom has dpendencies that have been tested together. Provided in dependency management so can choose what need
  • Proved @Component still creates a @Bean
  • SpringApplication.run returns a ConfigurableApplicationContext. We don’t typically use it directly, but can look into it.
  • ApplicationRunner (creates prop object from args) vs CommandLineRunner (has args as array). The later is slightly more efficient.
  • @Value lets you get a property

Overwriting name

  • application.properties with wrong key name. Typo causes code not to use the value
  • application.yaml – ignored; still uses application.properties because higher precedence

Actuator

  • Can expose a lot of info
  • By default, opens two endpoints, status and one other. If want actual info, allow by privilege.
  • Can expose everything via management.endpoints.webexposure.include=* (don’t do this in prod)
  • loalhost:8080/actuator – see endpoints
  • localhost:8080/actuator/env – see java version, list of beans, etc (so can see order)

Remote debugging

  • In IDE config, set -agentib:jdwp=transport=dt_socket,server.. (missed the end)

Container

  • Can set config in Docker fil.

Key point

You don’t know. You can suspect and hypothesize, but not assume.

My take

I like that Mark showed Spring source code to show what was happening. It took a long time to get to the first thing that went wrong (missing property).. (40 minutes in; another session was already applauding by then). Once he got to that part, I started learning stuff. Mark also seemed rushed for the end and that info went too fast for me. (Combo if it being new and I think he was going faster) Also, the using the audience members as names in the example was fun.