DEV Community: Christina Lin

Is Java Spring Ready for the AI Overlords in Late 2025? My Take(and rant) on Building an MCP Server.

Christina Lin — Thu, 30 Oct 2025 20:55:08 +0000

Alright, confession time. Before I jumped on the Python bandwagon a couple of years ago, I was a die-hard Java dev. In this day and age, you’ve gotta be bilingual and flexible enough to pick the right tool for the job. And let’s be honest, for most AI stuff, Java hasn’t exactly been the cool kid at the party.

But with the industry flooded with examples of building MCP servers in Python, TypeScript, and whatnot, I got curious. What’s Java been up to?

Since I’m putting together a lab on securing MCP servers, I figured, why not build one in Java? After a couple of days of digging, my hot take is: Jeeez, can you make up your mind? I looked at SDKs, examples, and documentation. Depending on when it was written, you’ll see a huge difference in package names, and even the annotation names change. This API churn isn’t just annoying for us humans and of course it completely confuses the LLMs. They rely on a stable corpus of code to learn from, and right now, that just doesn’t exist for Spring AI.

So, here’s my verdict for now: I’ll probably wait a few more months before I’d push this to production. It’s not that it’s bad, but if you need to migrate to a new version, it feels like a complete rewrite.

Okay, enough of my rant (can’t call myself a millennial developer if I don’t complain a little).

Here’s the technical breakdown of how I got a mock MCP server running.

A quick heads-up: I’m writing this at the end of October 2025, and I’m using version 1.1.0-M3 of Spring AI. If you’re reading this in the future and all my code looks wrong, it’s probably because the Spring team decided to refactor everything. Again. 😉

Now, before we get our hands dirty with code, let’s make sure we’re on the same page. I’m guessing most of you are already building these things, but for anyone new to the party, here’s the lowdown on what an MCP server is. An MCP server is basically a standalone server that you pack with tools, think specific functions or API calls. The magic is that an AI agent can connect to your server, discover all the tools you’ve exposed, and then intelligently decide to use them to accomplish real world tasks. It’s how you give your LLM superpowers beyond just generating text. Instead of the AI just talking about shipping a package, it can actually call your shipPackage tool and make it happen. Simple as that.

Alright, preamble over. Let’s get to the POM.

Step 1: Bootstrap the Project with Spring Initializr

Like any good old Spring application, our journey begins at the same sacred place: the Spring Initializr.

Head over to start.spring.io and punch in your specs. I’m sticking with my old mate Maven, but you do you. Here are the key settings:

Project: Maven
Language: Java
Packaging: Jar
Java: 17 or 21

For the dependencies, you only need to add one to start: Spring MCP Server. The MCP MVC specific stuff isn’t in the main generator yet, so we’ll add that manually in the next step.

Go ahead, fill that out, click ‘GENERATE’, and unzip the project into your favorite IDE. Now we’re ready for the real work.

Step 2: Wrangling the POM

Once you’ve got the project open, the first place we need to operate is the pom.xml. The Spring Initializr gave us a good starting point, but now we need to perform some surgery and add the Spring AI dependency for our MCP server.

  <dependencies>
        <dependency>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-starter-web</artifactId>
       </dependency>
       <dependency>
           <groupId>org.springframework.ai</groupId>
           <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>
       </dependency>
       <dependency>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-starter-test</artifactId>
           <scope>test</scope>
       </dependency>
   </dependencies>

The key dependency here is spring-ai-starter-mcp-server-webmvc. Its main job is to provide the web layer, enabling protocols like streamable HTTP or Server-Sent Events (SSE). It acts as a bridge, pulling in the core spring-ai-mcp-server libraries where the actual tool discovery logic lives. So, by adding this one starter, you’re effectively telling Spring Boot, “I want an MCP server, and I want it to speak HTTP.” It’s the combination of the web-specific and core libraries on the classpath that kicks off the whole auto-configuration chain, wiring everything together from endpoints to tool scanners.

Alight, and another very important point because I don’t want to have everything outdated, I’ll pick the latest version of Spring AI, which currently is

<spring-ai.version>1.1.0-M3</spring-ai.version>

Spring Boot’s auto-configuration lets us control a ton of behavior without writing a single line of Java config. Here’s how I set it up in application.properties:

spring.application.name=mcp-server
server.port=8081
spring.ai.mcp.server.protocol=streamable
spring.ai.mcp.server.name=physical_operations_logistics_mcp
spring.ai.mcp.server.capabilities.tool=true
spring.ai.mcp.server.type=sync
spring.ai.mcp.server.annotation-scanner.enabled=true
spring.ai.mcp.server.streamable-http.keep-alive-interval=20s
spring.ai.mcp.server.version=0.0.1

A couple of these are super important.

spring.ai.mcp.server.annotation-scanner.enabled=true is what tells Spring to go on a scanning at startup. It uses reflection to find any beans you’ve annotated with @McpTool and dynamically builds a machine-readable tool catalog (a JSON schema, basically). spring.ai.mcp.server.streamable-http.keep-alive-interval=20s . It keeps the long-lived HTTP connection from getting killed by an impatient proxy or load balancer.

Step 3: Building the Tools

Now for the fun part. Since we’re in Java-land, we’re going to lean into its object-oriented nature. It just makes sense to categorize our tools by their domain. Instead of having a bunch of disconnected functions floating around, we’ll group all the related tools into a single, cohesive class. This is classic OOP, a class should represent a single responsibility or concept.

In our case, all the tools for handling employee hardware and building access belong together. So, we’ll create a PhysicalOperationsLogisticsService class. This class acts as a dedicated service layer for that specific business domain. This approach not only keeps the code clean and organized but also fits perfectly with Spring’s component model. We can just slap a @Component annotation on the class, and boom, it becomes a managed bean in the Spring container.

package google.mcp;


import org.springaicommunity.mcp.annotation.McpTool;
import org.springaicommunity.mcp.annotation.McpToolParam;
import org.springframework.stereotype.Component;


import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.time.LocalDate;
import java.util.List;
import java.util.UUID;


@Component
public class PhysicalOperationsLogisticsService {


   private static final Logger log = LoggerFactory.getLogger(PhysicalOperationsLogisticsService.class);


   @McpTool(name = "provisionBuildingAccess",description = "Activates a security badge for building access at a specific office.")
   public String provisionBuildingAccess(
           @McpToolParam(description = "The ID of the employee.") String employeeId,
           @McpToolParam(description = "The office location for building access.") String officeLocation) {
       log.info("Provisioning building access for employee {} at {}", employeeId, officeLocation);
       return "{\"access_status\": \"active\"}";
   }


   @McpTool(name = "shipPackage",description = "Places an order for a physical hardware package from a vendor.")
   public String shipPackage(
           @McpToolParam(description = "The ID of the order.") String orderId,
           @McpToolParam(description = "The recipient's address as a JSON string.") String recipientAddress,
           @McpToolParam(description = "Description of the package contents.") String packageContents) {
       log.info("Shipping package for order {} to {} with contents {}", orderId, recipientAddress, packageContents);
       String trackingNumber = UUID.randomUUID().toString();
       LocalDate estimatedDelivery = LocalDate.now().plusDays(7);
       return String.format("{\"order_id\": \"%s\", \"tracking_number\": \"%s\", \"estimated_delivery\": \"%s\"}",
               orderId, trackingNumber, estimatedDelivery.toString());
   }


   @McpTool(name = "getShippingStatus",description = "Gets the latest status of a package from a shipping carrier.")
   public String getShippingStatus(
           @McpToolParam(description = "The tracking number of the package.") String trackingNumber) {
       log.info("Getting shipping status for tracking number {}", trackingNumber);
       String[] statuses = {"in_transit", "delivered", "delayed"};
       String status = statuses[(int) (Math.random() * statuses.length)];
       return String.format("{\"shipping_status\": \"%s\"}", status);
   }
}

Let’s break down those annotations:

@McpTool: This tells the scanner, “Hey, this method is a tool!” The name and description are critical. The LLM uses the description to figure out when to call your tool. A good description is the difference between a useful tool and a useless one.
@McpToolParam: This one works on the method arguments. It generates the schema for the parameters, defining their names, types (inferred from Java), and a description of what the parameter is for.

Step 5: Build, Run, and See It in Action

Building and running is standard Maven fare:

# Compile, test, and package into an executable JAR
mvn clean package

# Fire it up
mvn spring-boot:run

To test it, I wired up the Gemini CLI. I just had to point it to my local server in its settings.json:

{
  "mcpServers": {
    "physical-logistic-server": {
      "httpUrl": "http://localhost:8081/mcp"
    }
  }
}

Here’s the technical play-by-play of what happens next:

The Gemini CLI hits http://localhost:8081/mcp and asks, “What can you do?”
My Spring server proudly presents the JSON schema it built from my annotations.

I give Gemini CLI a prompt like, “what’s the shipping status for tracking number xxxx?”
Gemini CLI sees my prompt, looks at the available tools, and says, “Aha! The getShippingStatus tool looks perfect for this.” It then generates a function call payload.
Gemini CLI sends that payload to my Spring MCP server, which routes it to the getShippingStatus method.
My Java code runs, does its mock magic, and returns a JSON string.
Gemini CLI passes that result back to the LLM, which then formulates a nice, human-readable answer.

Final Thoughts

Once you get past the version whiplash, the framework is actually pretty slick. It hides a lot of complexity behind familiar Spring annotations and auto-configuration. For Java builders looking to get their hands dirty with AI, it’s a promising start.

That said, given its current milestone status, I’d keep it in the lab for now. I’ll be watching for a stable GA release before I’d even think about letting it near production.

As for the full code, I’ll be sharing that in my security workshop. Stay tuned.

Software Becomes Disposable?How AI Is Changing the Way We Architect Code

Christina Lin — Wed, 15 Oct 2025 15:06:23 +0000

I still remember the days when I worked at a large insurance company, the kind of enterprise where COBOL still runs in the core systems, quietly but powerfully. No one dared to touch that code. It was the kind of legacy that everyone respected, feared, and tiptoed around.

At that time, if you asked any engineer why we never refactored it, the answer was simple:

“No one really knows what will happen if we do.”

The system worked.... barely, but it was a black box of decades-old logic, dependencies, and undocumented behaviors.

The Satellite System Problem

Since no one dared to modify the core, over the years, people started building satellite systems around it, smaller applications that added new features faster, without waiting for the core to evolve. It was pragmatic. Business got what it needed, engineers could deliver something visible, and everyone avoided the monster in the basement.

But after a few years, even the satellites started to show cracks. These systems became complex in their own right.... Full of duplicated logic, inconsistent data flows, and patches built on patches.

At one point, I proposed refactoring one of these satellite systems. Everyone hesitated. “Too risky,” some said. “Too much work,” said others. But the system was becoming unmaintainable, and new features took forever to build.

We decided to do it anyway.

It took six months. Six painful months of long hours, regression testing, and endless rounds of debugging. Along the way, we discovered an absurd amount of duplicate logic, dead code, unused modules, and plain rubbish.

In the end, we pulled it off. The system became faster, cleaner, and easier to understand. But it came at a massive human cost — time, effort, and anxiety.

Now, Doing That with AI

Fast forward to today.

With AI-assisted development, refactoring that same system would look completely different.

AI tools can now analyze the structure of codebases, map dependencies, and summarize business logic with impressive accuracy. They can generate or improve test cases automatically, and even suggest refactoring strategies that would take a human team weeks to plan.

When you have an intelligent system that can:

Understand code semantics, not just syntax
Identify duplicated logic across thousands of files
Auto-generate integration tests
Suggest consistent naming conventions and abstractions

…then the cost of refactoring drops dramatically.

Suddenly, legacy systems are no longer sacred monuments — they’re just old code that can be replaced, rewritten, or modernized in a fraction of the time.

And that changes everything.

Software with an Expiration Date

Historically, software longevity was a badge of honor. We built systems to last. Stability was everything.

But what if that assumption no longer makes sense?
If AI can rewrite or refactor systems easily, the lifespan of software will naturally get shorter. The value shifts from building something “permanent” to building something “adaptable.”

Software might become more disposable??!! Actually.. that’s not necessarily a bad thing.

When refactoring and rewriting are cheap, there’s less reason to over-engineer architectures for long-term maintainability. Instead of spending months perfecting the perfect layered model or microservice pattern, we might favor simpler, more generic designs that are easy for AI to understand and modify.

Rethinking Software Architecture

For decades, our industry has cycled through design philosophies — from monoliths to microservices to service meshes to event-driven architectures. Every few years, we rename or repackage the same ideas: separation of concerns, modularity, reusability.

But if AI becomes a key player in maintaining and evolving systems, maybe the best architecture is the one AI can reason about most easily.

That means:

Less clever abstractions, more transparency
Simpler patterns, fewer custom frameworks
More consistent conventions, fewer human quirks

We might design software not just for humans to maintain... but for AI to understand, refactor, and evolve continuously.

In that world, architecture becomes less about rigidity and more about fluidity. You don’t freeze designs for a decade, you evolve them weekly, safely, and automatically.

The Human Shift

This doesn’t make engineers obsolete, it just changes what we focus on.

Instead of fighting technical debt manually, we’ll define refactoring policies and semantic constraints that guide AI. We’ll spend more time thinking about business logic, domain modeling, and user needs, while AI handles the plumbing, code cleanup, and modernization.

The skill set shifts from “how do I write this class elegantly?” to “how do I describe this system so that AI can evolve it intelligently?”

Where Human Expertise Still Reigns

Of course, this vision of disposable software doesn’t apply everywhere. Not all code will become a generic, AI-managed commodity. Deep human intervention will remain non-negotiable in specialized domains where performance and precision are paramount.

Think of high-frequency trading platforms, core engines, or kernels. In these arenas, engineers aren't just writing logic, they're squeezing every last nanosecond of performance from the hardware. This requires a level of bespoke optimization and creative, low-level mastery that AI can assist with but not lead. The same holds true where knowledge is highly enclosed within a specific domain, like the firmware for medical devices or avionic systems. In these mission-critical cases, the final architecture and code will always be shaped by human expertise, accountability, and deep domain knowledge.

The New Philosophy of Software

In the AI era, the best codebase might not be the most elegant or the most performant, it might be the one that’s most refactorable.

We’ll stop thinking of software as monuments and start treating them like living organisms, constantly regenerating, adapting, and shedding obsolete parts.

The irony? AI might finally allow us to break free from the legacy trap... from those untouchable COBOL systems that still haunt large organizations.

The systems of the future won’t last 30 years. They might last three and that’s perfectly fine. Because when refactoring is cheap, software doesn’t need to live forever.

Back then, refactoring that insurance satellite system was a heroic project. Today, it could be a weekend job... Not because we’re smarter, but because our tools are.

So maybe the right mindset going forward isn’t “build to last,” but “build to evolve.” Software’s new strength won’t be in its permanence, it’ll be in its disposability.

Disclaimer: The opinions expressed in this post are my own.

The Happy Path Lie: A Developer’s Critique of Low-Code and the AI-Powered Future

Christina Lin — Thu, 09 Oct 2025 13:02:25 +0000

A colleague and I were talking the other day about why I don't really create content about drag-and-drop, low-code platforms. I'm very opinionated on this topic. While these tools have an amazing sales pitch, my long years in this industry have taught me that their promise is mostly a fantasy. For all the slick demos and claims of democratizing development, they often create more problems than they solve.

The Beautiful Lie of the "Happy Path"

The biggest problem with low-code platforms is that their demos only ever show you the "happy path." This is the perfect, sterile scenario where the user does everything exactly right, the data is flawless, and no weird, unexpected things ever happen.

But the real world is anything but a happy path. It's a messy, chaotic place full of edge cases. What happens when a user uploads the wrong file type? Or when an external API you're connected to suddenly goes down?

That's where the beautiful drag-and-drop interface begins to crumble. To handle these real-world scenarios, you inevitably have to write code. Suddenly, you're right back where you started, only now you’re trying to shoehorn custom logic into a system that was fundamentally designed to hide it from you. It feels like trying to fix a car's engine through the glove box.

The Nightmare of Hidden Code

This leads to the next big headache: your UI and the actual logic underneath it get out of sync. You have this clean-looking visual flow, but it's lying to you. It doesn't show the custom scripts, the workarounds, and the emergency patches you’ve had to bolt onto the components.

Imagine a new developer joining the team. They look at the drag-and-drop interface and think, "Oh, this is simple!" But they have no idea about the tangled web of custom code lurking just beneath the surface. This "black box" operation makes the application incredibly difficult to debug and maintain. What you see is definitely not what you get, and that’s a recipe for disaster.

Trapped in the Past: The Perils of Vendor Lock-In

Now, let's talk about the long game. What happens in five, ten, or even twenty years? In my experience, I have yet to see a company handle the lifecycle of these applications well.

You often get stuck with two terrible options:

You’re chained to a legacy UI because that’s the version the original drag-and-drop system supports. It’s ancient, clunky, and can’t handle modern needs, but you can't leave.

You trust the vendor's "migration tool" to move to their latest version. These tools are often faulty and almost never account for the custom code you wrote for those edge cases. Your application breaks, and you’re left picking up the pieces.

This is what we call vendor lock-in. Because most of these platforms don't give you access to the underlying source code, it's almost impossible to pack up your application and move it somewhere else. You're stuck in their ecosystem, and the cost of leaving—in time, money, and sheer frustration is just too high.

The New Wave of AI Tools: Are We Just Going Backwards?

But wait," I hear you say. "What about the new, developer-focused tools for AI and automation? Things like n8n, the new AgentKit from OpenAI, or even some of the agent-building tools from Google? They use visual, node-based interfaces. Isn't that the future?"

I would question that. In fact, I believe it's a dangerous regression, dressing up old problems in the shiny new clothes of AI.

The core issue hasn't changed; it has just moved from the front-end to the back-end. Instead of abstracting away UI components, we are now abstracting away the logic of AI agents and their calls to LLMs. Each node on the canvas looks clean, but it can hide a mountain of complex, custom code.

Yes, for a new developer or someone looking for a quick win, this visual approach provides a clear path to building a simple workflow. In the short term, everything feels awesome. But this isn't an evolution; it's history repeating itself. We're so enamored with the power of AI agents that we're immediately reaching for the same flawed visual abstractions that have failed us before. We are simply creating the legacy maintenance problems of tomorrow, today.

The Bottom Line: A Developer's Crossroads

So, where does this leave us?

Here's my hot take: as AI gets better at understanding our intentions and writing clean, efficient code, the need for that restrictive drag-and-drop layer will finally disappear. Why would a developer want to be constrained by a visual builder when they can just tell an AI what they want to build and have it generate the code for them?

This is the true power of AI-native development. We won't lose the benefits of visualization; we'll enhance them. Imagine an LLM that not only generates the code but can also create an interactive architecture diagram from that code on the fly. Visualization becomes a feature of the code, not a cage it's trapped in.

This opens up a much more interesting question for our industry: How do we, as developers, build the tools that solve the original problem in a better way? How can we leverage AI to make coding itself more accessible, without the pitfalls of vendor lock-in and hidden technical debt?

The future isn't about hiding code behind drag-and-drop boxes. It's about creating intelligent tools that help people write better code, faster. It’s about turning a developer’s idea into a functional, robust application with as little friction as possible.

So, the next time you see a perfect low-code demo, remember the messy reality behind the curtain. But also, get excited. We're on the verge of a new era where the best development tool isn't a restrictive UI—it's a conversation. And as the creators of these new tools, we won't need a "happy path," because we'll have the power to build a road to wherever we need to go.

Disclaimer: The opinions expressed in this post are my own.