Java has come a long way in the recent years.

In this two part presentation, we will learn about the exciting features including modularization, text blocks, records, sealed classes, pattern matching, and also how these features interplay with each other to provide the most flexibility and power to you to create fluent code.

Java has come a long way in the recent years.

In this two part presentation we will learn about the exciting features including modularization, text blocks, records, sealed classes, pattern matching, and also how these features interplay with each other to provide the most flexibility and power to you to create fluent code.

We are knowledge workers and ultimately, we must own our growth and learning. Personal Knowledge Management is a process of collecting information that one uses to gather, classify, store, search, retrieve and share knowledge in their daily activities and the way in which these processes support work activities.

Despite taking notes, bookmarking web content, and highlighting passages in books; often we struggle to recall or rediscover these many insights we pick up daily in our work and life. This session introduces a tool and some process recommendations to never again lose discoveries and knowledge resources.

Michael shares the tools and workflow he (and many on the NFJS tour) use to write, organize and share your thoughts, keep your todo list, and build your own digital garden. These approaches naturally connects what you know the same way your brain does, and makes it easier to make everything you learn actionable and always at your fingertips.

You'll learn the basics, tips and tricks, and recommendations of these tools and practices; and leave armed to deploy these right away as you continue learning at the conference!

Architecture is often described as “the stuff that's hard to change” or “the important stuff (whatever that is).” At its core, architecture defines the very essence of software, transcending mere features and functions to encompass vital capabilities such as scalability, evolvability, elasticity, and reliability. But here's the real question: where do these critical capabilities truly originate?

In this session, we'll embark on a journey to uncover the secrets behind successful architectures. While popular architecture patterns may offer a starting point, it's time to unveil the startling truth – both monolith and microservicesbased projects continue to stumble and falter at alarming rates. The key to unparalleled success lies in the art of finetuning and tailormaking architectures to precisely fit the unique needs of your organization, environment, and the teams delivering the software.

Step into the future as we introduce a groundbreaking, problemcentric approach to defining and evolving system architectures. Our practical techniques will empower you to transform constraints, both architectural and environmental, into powerful enablers of robust, valuable, and longlived software systems.

Join us and elevate your architecture game to new heights!

Containers are everywhere. Of course, a large part of the appeal of containers is the ease with which you can get started. However, productionizing containers is a wholly different beast. From orchestration to scheduling, containers offer significantly different challenges than VMs.

In particular, in terms of security. Securing and hardening VMs is very different than that for containers.

In this twopart session, we will see what securing containers involves.

We'll be covering a wide range of topics, including

Understanding Cgroups and namespaces
What it takes to create your own container technology as a basis of understanding how containers really work
Securing the build and runtime
Secrets management
Shifting left with security in mind

Containers are everywhere. Of course, a large part of the appeal of containers is the ease with which you can get started. However, productionizing containers is a wholly different beast. From orchestration to scheduling, containers offer significantly different challenges than VMs.

In particular, in terms of security. Securing and hardening VMs is very different than that for containers.

In this twopart session, we will see what securing containers involves.

We'll be covering a wide range of topics, including

Understanding Cgroups and namespaces
What it takes to create your own container technology as a basis of understanding how containers really work
Securing the build and runtime
Secrets management
Shifting left with security in mind

In this session we'll take a tour of some features that you might or might not have heard of, but can significantly improve your workflow and day-to-day interaction with Git.

Git continues to see improvements daily. However, work (and life) can take over, and we often miss the changelog. This means we don't know what changed, and consequently fail to see how we can incorporate those in our usage of Git.

In this session we will look at some features you are probably aware of, but haven't used, alongside new features that Git has brought to the table. Examples include:

• Rebase and interactive rebase
• restore/switch and when to use them
• worktrees
• shallow-clones
• Git's filesystem monitor

By the end of this session, you will walk away with a slew of new tools in your arsenal, and a new perspective on how this can help you and your colleagues get the most out of Git.

We keep hearing the chants, functional programming is awesome, reactive programming is superb, asynchronous programming is the future, reactive programming is dead, functional programming will result in poor performance, and so on. There is partial truth in almost all those statements, but not understanding the details can lead to poor judgement and loosing out on the benefits of the different paradigms.

In this presentation we will take an objective look at each of these paradigms, understand their powers and also their weakness, where they are alive, and in what context they may appear to be dead, and when we should leverage these, and when we may want to look for alternatives.

Creating microservices takes substantial effort but maintaining them in production takes a lot more time, cost, and effort. If we forget some key practices the results can be devastating for the organization and we end up hurting from the lack of the measures we can put in place to proactively address potential issues.

In this presentation we will discuss seven essential practices to make the journey of maintaining microservices in production.

By their very nature, distributed applications have to communicate. But, how do we exchange data and what are the consequences of choosing one solution over the other, in terms of ease, cost, impact on extensibility, and so much more.

In this presentation we will discuss different patterns, their benefits, and the consequences of using them.

On the NFJS tour, there are questions that seem to come up again and again. One common example is “How do we determine which new tools and technologies we should focus our energy on learning?” another is “How do we stop management from forcing us to cut corners on every release so we can create better and more maintainable code?” which, after awhile becomes “How can we best convince management we need to rewrite the business application?”

There is a single metaanswer to all these questions and many others.

It begins with the understanding that what we as engineers value, and what the business values are often very different (even if the ultimate goals are the same) By being able to understand these different perspectives it's possible to begin to frame our arguments around the needs and the wants of the business. This alone will make any engineer significantly more effective.

This session picks up from where “Stop writing code and start solving problems” stops discussing what is value, how do we align the values of the business with the needs and values of the engineer.

In this session we will discuss what modular monoliths are, what they bring to the table, and how they offer a great middle ground between monoliths and distributed architectures like microservices.

Monoliths get a bad rep. Experienced software developers have seen one too many monoliths devolve into a big ball of mud, leaving everyone frustrated, with an itch to do a “rewrite”. But monoliths have their pros! They are usually simpler, easier to understand, and faster to build and debug.

On the other side of the spectrum you have microservices—that offer scale, both technically and organizationally, as well as having the badge of honor of being “the new cool kid on the block”. But productionizing microservices is HARD.

Why can't we have our cake and eat it too? Turns out, we can. In this session we will explore the modular monolith—all the upsides of a monolith with none of the downsides of distributed architectures. We'll see what it means to build a modular monolith, and how that differs from a traditional layered architecture. We will discuss how we can build architectural governance to ensure our modules remain decoupled. Finally we'll see how our modules can communicate with one another without violating modularity.

By the end of this session you'll walk away with a greater appreciation for the monolith, and see how you can leverage this within your system architecture.

It's not just architecture—it's evolutionary architecture. But to evolve your architecture, you need to measure it. And how does that work exactly? How does one measure something as abstract as architecture?

In this session we'll discuss various strategies for measuring your architecture. We'll see how you know if your software architecture is working for you, and how to know which metrics to keep an eye on. We'll also see the benefits of measuring your architecture.

We'll cover a range of topics in this session, including

Different kinds of metrics to measure your architecture
The benefits of measurements
Improving visibility into architecture metrics

Introducing Spring Modulith

Although microservices are still a useful architectural choice, the balance of additional complexity and the advantages of microservice architecture do not necessarily work out in the benefit of all applications. While most application will benefit from improved modularity, the challenges that come with distributed computing may be too much for some applications to take on. A well-structured and modular monolithic application might be a better fit.

In this session, we'll explore Spring Modulith, a relatively new Spring library that enables developers to build well-structured Spring Boot applications, guiding them in discovering domain-driven modules, and verifying that the modular arrangement is correct. We'll also see how Spring Modulith assists with modular integration testing and documentation.

In this example-driven session, we'll review several tips and tricks to make the most out of your Spring development experience. You'll see how to apply the best features of Spring and Spring Boot, including the latest and greatest features of Spring Framework 6.x and Spring Boot 3.x with an eye to what's coming in Spring 7 and Boot 4.

Spring has been the de facto standard framework for Java development for nearly two decades. Over the years, Spring has continued to evolve and adapt to meet the ever-changing requirements of software development. And for nearly half that time, Spring Boot has carried Spring forward, capturing some of the best Spring patterns as auto-configuration.

As with any framework or language that has this much history and power, there are just as many ways to get it right as there are to get it wrong. How do you know that you are applying Spring in the best way in your application?

Workshop Requirements

You'll need…

• A Java IDE of your choice. I'll be using IntelliJ, but you are welcome to use Spring Tools, Netbeans, or whatever you prefer for Java development. (Spring Tools–either the Eclipse or VSCode version–or IntelliJ is recommended, though).
• Java 17 or higher. I recommend using SDKMan (https://sdkman.io/) for managing multiple versions of Java on your machine. I'll be using Zulu 17.0.6 for most tasks, but may switch to a Liberica NIK version for purposes of native builds.
• Docker (optional, but may be necessary for some tasks)

Java advances quickly. It is incredible how much incremental change accumulates over time. JDK 17 is now three years old, and we are at JDK 22 as of 2025. In this session, I will take some select JEPs (Java Enhancement Process) and demonstrate what they are and their use case. Then you can be ahead of the curve, and give you all the information you need to sell and demand the next generation Java for your work or opensource initiative.

• How do you turn on these advanced features?
• Stream Gatherers
• Statements before super()
• Unnamed Variables and Parameters
• Launch Multi-File Source-Code Programs
• Implicit Declared Classes and Enhanced Main Methods
• Updates on switch expressions
• Stable Values

Threading has always been tough. Even with new frameworks that can make it easy, sometimes we don't have them at our disposal. This full-day session focuses on threading and the various synchronizers in Java. We will have material you can use as a reference and challenges that will help you remember some pitfalls to avoid.

• Concurrency vs. Parallelism
• Happens Before Guarantee
• volatile
• Starvation, Livelock, Deadlocks, and Race Conditions
• Using Composition over Inheritance
• Locks and choosing the right locks
• Wait, Notify, and Notify All
• Synchronizers
• CyclicBarrier
• Phaser
• CountdownLatch
• Semaphores

There is a new way of Threading, which means it is time to prepare. Project Loom has introduced Java Virtual Threads, which is now available in Java 21. Virtual Threads are small Threads meant to perform quick operations with the need to procure long-running OS threads, which can prove expensive. In this presentation, we will learn how to use these threads, what does it mean in relationship with the rest of the Java API, and what does it mean for third-party libraries.

• What is a Virtual Thread
• Creating and Using a Virtual Thread
• What will Loom's Virtual Threads do to Future and Reactive
• What is a Continuation?
• What is Structured Concurrency?
• What are Scoped Values

How do we move information realtime and connect machine learning models to make decisions on our business data? This presentation goes through machine learning and Kafka tools that would help achieve that goal.

In this presentation, we start with Kafka as our data backplane and how we get information to our pub/sub. As they enter Kafka, how do we sample that data and train our model, then how do we unleash that model on our real-time data? In other words, picture extracting samples for credit card approvals for training, then attaching the model for online processing: The moment we receive an application, we can either approve or disapprove a credit application based on a machine learning model trained on historical data. We will discuss other options as well like Spark, H2O, and more.

Domain Driven Design has been guiding large development projects since 2003, when the seminal book by Eric Evans came out. Domain Driven Design is split up into two parts: Strategic and Tactical. One of the issues is that the Strategic part becomes so involved and intense that we lose focus on implementing these sorts of things. This presentation swaps this focus as topic pairs. For example, when we create a bounded context, is that a microservice or part of the subdomain? When we create a domain event, what does that eventually become? How do other tactical patterns fit into what we decide in the strategic phase?

In this presentation, we will break it down into pairs of topics.

• Subdomains to Architecture Boundaries
• Bounded Contexts
• Context Mapping
• Value Objects, Entities, and Aggregates
• Where do Microservices fit in?
• How do subdomains and bounded contexts fit in?
• Where do we put human beings in all this?
• What is Event Storming

“What you must learn is that these rules are no different than the rules of a computer system. Some of them can be bent. Others can be broken. "
-Morpheus

The world of technology seems logical, objective, and to operate by consistent rules. Reality can be illogical, subjective, and even random at times. Yet we accept subjective reality as-is; our single perspective is all we can really know.

In the end, reality constrains engineers and magicians reshape reality. Perhaps reality is not what it seems.

Join Michael Carducci, magician and software architect, as he takes you on a journey through the marriage of the logical and the illogical, the intersection of magic and technology. Discover what each has to teach the other, and how you can apply the lessons to transform your skills and your career.

With over 25 years of experience in both fields–and a lifetime of successes and failures–Michael shares his deeply reflective, unique, and authentically honest perspective on both careers, dealing with problems, challenges, wins, and losses.

This talk combines illusion, engineering wisdom, life lessons, and the stories that connect them. You'll be astonished, engaged, and leave with an entirely new perspective on technology and life.

In this session we will discuss the need to document architecture, and see what mechanisms are available to us to document architecture—both present and future.

We've all learned that documenting your code is a good idea. But what about your architecture? What should we be thinking about when we document architecture? What tools and techniques can we reach for as we pursue this endeavor? Can we even make this a sustainable activity, or are we forever doomed to architectural documentation getting outdated before the ink is even dry?

In this session we will discuss a range of techniques that will not only help document your architecture, but even provide a mechanism to think about architecture upfront, and make it more predictable. You'll walk away armed with everything you need to know about documenting your current, and future architectures.

REST is, undoubtedly one of the most maligned and misunderstood terms in our industry today. So many different things have been called REST, that the world has virtually lost all meaning. Many systems and applications that self-describe as “RESTful” usually are not, at least according to REST as defined in Dr. Roy T. Fielding’s 2000 Dissertation, “Architectural Styles and the Design of Network-based Software Architectures”.

The wild success of the architecture derived by Dr. Fielding led many to want to emulate it (even when it was inappropriate to do so). As a shorthand, organizations began referring to “RESTful” systems, which exposed “RESTful” APIs. Over time “REST” became a buzzword referring to a vague generalization of HTTP/json APIs that typically bear little to no resemblance to the central ideas of REST (and thus elicit few of the benefits). Hypermedia is the central pillar and defining characteristic of the REST architectural style yet it remains almost universally absent.

Hypermedia was a revolutionary idea that, while more relevant than ever, is almost forgotten in today's tech space. Consequently few reap the benefits of this idea and ever fewer know what they might be giving up.

Although not every system needs to (or should be) RESTful, it's helpful to understand the key–and often overlooked–ideas to be able to decide if they make sense for your current next project. This session introduces the key foundational ideas and shows what these ideas look like in practices. Although hypermedia and REST don't make sense for every project or system, you'll leave this session with a better understanding of these groundbreaking ideas, practical insights on how to adopt them today, and ultimately armed to approach the trade-offs of this approach mindfully and deliberately.

In 2017, an organization known as The Semantic Arts published their “datacentric manifesto” leading with this paragraph.

&gt “We have uncovered a root cause of the messy state of Information Architecture in large institutions and on the web today. It is the prevailing applicationcentric mindset that gives applications priority over data. The remedy is to flip this on its head. Data is the center of the universe; applications are ephemeral.”

While the vision and ideas of this manifesto are compelling, implementation details are scarce leaving the potential out of reach of many busy developers and architects.

Datacentric is a major departure from the current applicationcentric approach to systems development and management. Migration to the datacentric approach will not happen by itself.

This session is full of practical and actionable examples, insights, and approaches to this new paradigm. If you’re ready to consider the possibility that systems could be more than an order of magnitude cheaper and more flexible, then check out this session to see firsthand a new way to think about software and information systems.

It's not just you. Everyone is basically thinking the same thing: When did this happen?

We've gone from slow but steady material advances in machine learning to a seeming explosion and ubiquity of AI-based features, products, and solutions. Even more, we're all expected to know how to adopt, use, and think about all of these magical new capabilities.

Equal parts amazing and terrifying, what you need to know about these so-called “AI” solutions is much easier to understand and far less magical than it may seem. This is your chance to catch up with the future and figure out what it means for you.

In this two part presentation, we will cover why this time it is different, except where it isn't. I won't assume much background and won't discuss much math.

A brief history of AI
Machine Learning
Deep Learning
Deep Reinforcement Learning
The Rise of Generative AI
Large Language Models and RAG
Multimodal Systems
Bias, Costs, and Environmental Impacts
AI Reality Check

At the end of these sessions, you will be conversant with the major topics and understand better what to expect and where to spend your time in learning more.

It's not just you. Everyone is basically thinking the same thing: When did this happen?

We've gone from slow but steady material advances in machine learning to a seeming explosion and ubiquity of AI-based features, products, and solutions. Even more, we're all expected to know how to adopt, use, and think about all of these magical new capabilities.

Equal parts amazing and terrifying, what you need to know about these so-called “AI” solutions is much easier to understand and far less magical than it may seem. This is your chance to catch up with the future and figure out what it means for you.

In this two part presentation, we will cover why this time it is different, except where it isn't. I won't assume much background and won't discuss much math.

A brief history of AI
Machine Learning
Deep Learning
Deep Reinforcement Learning
The Rise of Generative AI
Large Language Models and RAG
Multimodal Systems
Bias, Costs, and Environmental Impacts
AI Reality Check

At the end of these sessions, you will be conversant with the major topics and understand better what to expect and where to spend your time in learning more.

There is plenty of discussion about how machine learning will be applied to cybersecurity initiatives, but there is precious little conversation about the actual vulnerabilities of these systems themselves. Fortunately, there are a handful of research groups doing the work to assess the threats we face in systematizing datadriven systems. In this session, I will introduce to the main concerns and how you can start to think about protecting against them.

We will mostly focus on the research findings of the Berryville Institute of Machine Learning. They have conducted a survey of the literature and have identified a taxonomy of the most common kinds of attacks including:

• Adversarial examples
• Data poisoning
• Manipulation of online systems
• Transfer learning attacks
• Breaching data confidentiality
• Undermining data trust

This will be a securityfocused discussion. Only basic understanding of machine learning will be required.

Application Programmer Interfaces (APIs) by definition are directed at software developers. They should, therefore, strive to be useful and easy to use for developers. However, when engaging design elements from the Web, they can be useful in much larger ways than simply serializing states in JSON.

There is no right or perfect API design. There are, however, elements and choices that induce certain properties. This workshop will walk you through various approaches to help you find the developer experience and long-term strategies that work for you, your customers and your organization.

Application Programmer Interfaces (APIs) by definition are directed at software developers. They should, therefore, strive to be useful and easy to use for developers. However, when engaging design elements from the Web, they can be useful in much larger ways than simply serializing states in JSON.

There is no right or perfect API design. There are, however, elements and choices that induce certain properties. This workshop will walk you through various approaches to help you find the developer experience and long-term strategies that work for you, your customers and your organization.

Agile has become an overused and overloaded buzzword, let's go back to first principles. Agile is the 12 principles. Agile is founded on fast feedback and embraces change. Agile is about making the right decisions at the right time while constantly learning and growing.

Architecture, on the other hand, seems to be the opposite. Once famously described by Grady Booch as “the stuff that's hard to change” there is overwhelming pressure to get architecture “right” early on as the ultimate necessary rework will be costly at best, and fatal at worst. But too much complexity, too early, can be just as costly or fatal. A truly practical approach to agile architecture is long overdue.

This session introduces a new approach to architecture that enables true agility and unprecedented evolvability in the architectures we design and build. Whether you are a already a seasoned architect, or are simply beginning that path, this session will fundamentally change the way you think about and approach software architecture.

By now, you've no doubt noticed that Generative AI is making waves across many industries. In between all of the hype and doubt, there are several use cases for Generative AI in many software projects. Whether it be as simple as building a live chat to help your users or using AI to analyze data and provide recommendations, Generative AI is becoming a key piece of software architecture.

So how can you implement Generative AI in your projects? Let me introduce you to Spring AI.

For over two decades, the Spring Framework and its immense portfolio of projects has been making complex problems easy for Java developers. And now with the new Spring AI project, adding Generative AI to your Spring Boot projects couldn't be easier! Spring AI brings an AI client and templated prompting that handles all of the ceremony necessary to communicate with common AI APIs (such as OpenAI and Azure OpenAI). And with Spring Boot autoconfiguration, you'll be able to get straight to the point of asking questions and getting answers your application needs.

In this handson workshop, you'll build a complete Spring AIenabled application applying such techniques as prompt templating, Retrieval Augmented Generation (RAG), conversational history, and tools invocation. You'll also learn prompt engineering techniques that can help your application get the best results with minimal “hallucinations” while minimizing cost.

Workshop Requirements

In the workshop, we will be using…

• Java 17+
• An IDE of your choosing (I will be using IntelliJ IDEA)
• OpenAI's API (you will need an account and a small amount of credit $5 is more than enough).

Optionally, you may choose to use a different AI provider other than OpenAI such as Anthropic, Mistral, or Google Vertex (Gemini), but you will need an account with them and some reasonable amount of credit with them. Or, you may choose to install Ollama (https://ollama.com/), but if you do be sure to install a reasonable model (llama3:latest or gemma:9b) before you arrive.

Know that if you choose to use something other than OpenAI, your workshop experience will vary.

By now, you've no doubt noticed that Generative AI is making waves across many industries. In between all of the hype and doubt, there are several use cases for Generative AI in many software projects. Whether it be as simple as building a live chat to help your users or using AI to analyze data and provide recommendations, Generative AI is becoming a key piece of software architecture.

So how can you implement Generative AI in your projects? Let me introduce you to Spring AI.

For over two decades, the Spring Framework and its immense portfolio of projects has been making complex problems easy for Java developers. And now with the new Spring AI project, adding Generative AI to your Spring Boot projects couldn't be easier! Spring AI brings an AI client and templated prompting that handles all of the ceremony necessary to communicate with common AI APIs (such as OpenAI and Azure OpenAI). And with Spring Boot autoconfiguration, you'll be able to get straight to the point of asking questions and getting answers your application needs.

In this handson workshop, you'll build a complete Spring AIenabled application applying such techniques as prompt templating, Retrieval Augmented Generation (RAG), conversational history, and tools invocation. You'll also learn prompt engineering techniques that can help your application get the best results with minimal “hallucinations” while minimizing cost.

Workshop Requirements

In the workshop, we will be using…

• Java 17+
• An IDE of your choosing (I will be using IntelliJ IDEA)
• OpenAI's API (you will need an account and a small amount of credit $5 is more than enough).

Optionally, you may choose to use a different AI provider other than OpenAI such as Anthropic, Mistral, or Google Vertex (Gemini), but you will need an account with them and some reasonable amount of credit with them. Or, you may choose to install Ollama (https://ollama.com/), but if you do be sure to install a reasonable model (llama3:latest or gemma:9b) before you arrive.

Know that if you choose to use something other than OpenAI, your workshop experience will vary.

In this example-driven session, we're going to look at how to implement GraphQL in Spring. You'll learn how Spring for GraphQL builds upon GraphQL Java, recognize the use-cases that are best suited for GraphQL, and how to build a GraphQL API in Spring.

Typical REST APIs deal in resources. This is fine for many use cases, but it tends to be more rigid and less efficient in others.

For example, in an shopping API, it's important to weigh how much or how little information should be provided in a request for an order resource? Should the order resource contain only order specifics, but no details about the order's line items or the products in those line items? If all relevant details is included in the response, then it's breaking the boundaries of what the resource should offer and is overkill for clients that do not need it. On the other hand, proper factoring of the resource will require that the client make multiple requests to the API to fetch relevant information that they may need.

GraphQL offers a more flexible alternative to REST, setting aside the resource-oriented model and focusing more on what a client needs. Much as how SQL allows for data from multiple tables to be selected and joined in response to a query, GraphQL offers API clients the possibility of tailoring the response to provide all of the information needed and nothing that they do not need.

Workshop Requirements

• Java (17 or higher)
• An IDE of your choosing (I'll be using either Spring Tools or IntelliJ, but VSCode or even NetBeans will be fine if you prefer)