DEV Community: Jonathan Vila

7 habits of Highly Effective Java Coding

Jonathan Vila — Tue, 23 Sep 2025 17:16:04 +0000

From AI User to AI Pro

Let's be real, AI coding tools are everywhere now. 🤖 They're no longer some shiny new toy—they're a part of our daily grind as developers, just like our morning coffee. ☕
For us Java devs, whether we're wrestling with a giant legacy app or juggling a bunch of microservices, these tools look like a huge win for getting stuff done faster. 🚀
But here's the catch: just coding faster isn't the whole story. If you're not careful, it can actually lead to bigger problems down the road. 🤔
The real goal is to learn how to work with the AI to write code that's actually good—solid, secure, and won't give the next person on your team a headache or your company a serious problem.
This means we have to level up from being copy-paste machines and become smart developers who really know how to handle these powerful tools. 💪

So, I’m sharing 7 key habits that will help you do just that. This isn't just about speed; it's about getting way better at the job you love: 💡

1. The Golden Rule: Take Pride and Ownership in Your Craft 🥇
2. Feed the Beast: Your Project's Context is its Fuel ⛽
3. Dodge the "Ball of Mud": Keep Your Code Maintainable 🧠
4. Clean Your Room: No Stray Code or Sketchy Dependencies 🧹
5. Trust but review: Analyze the AI, the Code, and the Supply Chain 🕵️‍♀️
6. Beyond Coverage: Mandate Meaningful Tests ✅
7. The Human Gateway: A Code Review for What AI Can't See 🧠

1. The Golden Rule: Take Pride and Ownership in Your Craft 🥇

The first and most important habit isn't about blame; it's about pride and ownership. As developers, we are modern-day craftspeople. There's a deep, intrinsic satisfaction that comes from delivering high-quality, elegant, and robust code. This sense of pride is the foundation of a successful career and a healthy team dynamic. It’s what transforms a difficult pull request conversation into a collaborative design session and what turns the daily task of writing code into an opportunity for learning and mastery.

AI coding assistants are powerful new tools in our workshop, but like any power tool, they can be used to create beautiful work or to make a mess quickly. Blindly accepting AI-generated code is the fastest way to erode that professional pride. When you let unvetted code into your codebase, you're not just introducing potential bugs; you're forfeiting a chance to learn, to improve, and to stand behind your work with confidence. The rule isn't "you will be blamed"; it's "your name is on it, so make it something to be proud of."

From Painful PRs to Productive Conversations

We've all been in pull request (PR) reviews that feel like a slog. The comments are a long list of stylistic nits, potential null pointer exceptions, and questions like, "What is this part even supposed to do?". This often happens when code is rushed or not fully understood.

Now, imagine a PR where the code has high quality, the logic is clear, and the implementation is robust, and obviously you completely understand the code inside the PR. The conversation instantly elevates. Instead of nitpicking syntax, the team discusses architectural choices, business logic, and potential feature enhancements. This is where real collaboration happens.

By using AI as a starting point and then meticulously refining the output, you ensure your PRs fall into the second category. You are demonstrating to your team that you've done the hard work of thinking, not just the easy work of prompting. You own the solution, and the resulting discussion respects that ownership.

Technical Example: The AI's Brittle `CompletableFuture` vs. The Crafted Resilient Solution

Consider a common scenario in a microservices architecture: you need to build a user's dashboard by aggregating data from three different services concurrently. You ask an AI: “// Java: using CompletableFuture, concurrently fetch a user's details, their 5 most recent orders, and their product review count. Combine them into a single DTO and handle errors."

The AI, aiming for a direct solution, might produce something like this:

// AI-Generated First Draft - Brittle and Naive
public UserDashboardDTO getDashboard(long userId) throws Exception {
    // Fire off all requests in parallel
    CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(() -> userService.getById(userId));
    CompletableFuture<List<Order>> ordersFuture = CompletableFuture.supplyAsync(() -> orderService.getRecentForUser(userId, 5));
    CompletableFuture<Integer> reviewsFuture = CompletableFuture.supplyAsync(() -> reviewService.countByUser(userId));

    // Wait for all of them to complete
    CompletableFuture.allOf(userFuture, ordersFuture, reviewsFuture).join(); // The first major flaw

    // If we get here, all services succeeded.
    return new UserDashboardDTO(userFuture.get(), ordersFuture.get(), reviewsFuture.get()); // The second flaw
}

This code is a hidden landmine in a distributed system. 💣

Brittle Failure Mode: CompletableFuture.allOf(...).join() creates an "all-or-nothing" scenario. If just one of the services (e.g., reviewService) times out or throws an error, the join() call will throw an exception, and the entire operation fails. The user gets an error page instead of seeing their user details and orders, which were fetched successfully.
No Timeouts: There are no timeouts defined. If orderService is slow, this thread will hang indefinitely, consuming resources on your server.
Inefficient Composition: Calling .get() after the join() can re-throw exceptions and is less elegant than a proper composition chain.

A developer who takes pride in their craft recognizes that in a microservices world, partial communications and network failure is not rare. They refactor the code for resilience and graceful degradation.

// Human-Crafted, Professional Solution - Resilient and Robust
public UserDashboardDTO getDashboard(long userId) {
    ExecutorService customExecutor = Executors.newVirtualThreadPerTaskExecutor();

    // Each future is now a self-contained, resilient unit of work.
    CompletableFuture<User> userFuture = CompletableFuture
        .supplyAsync(() -> userService.getById(userId), customExecutor)
        .orTimeout(2, TimeUnit.SECONDS) // Set a reasonable timeout
        .exceptionally(ex -> new User.GuestUser()); // On error, return a default/guest user

    CompletableFuture<List<Order>> ordersFuture = CompletableFuture
        .supplyAsync(() -> orderService.getRecentForUser(userId, 5), customExecutor)
        .orTimeout(3, TimeUnit.SECONDS)
        .exceptionally(ex -> List.of()); // On error, return an empty list

    CompletableFuture<Integer> reviewsFuture = CompletableFuture
        .supplyAsync(() -> reviewService.countByUser(userId), customExecutor)
        .orTimeout(2, TimeUnit.SECONDS)
        .exceptionally(ex -> 0); // On error, return zero

    // Combine the results of the now-safe futures
    return CompletableFuture.allOf(userFuture, ordersFuture, reviewsFuture)
        .thenApply(v -> new UserDashboardDTO(
            userFuture.join(),
            ordersFuture.join(),
            reviewsFuture.join()
        )).join();
}

This professional solution is vastly superior. It handles failures gracefully within each asynchronous call using .exceptionally(), allowing the dashboard to render with partial data. It enforces timeouts with .orTimeout() to protect system resources. By explaining these choices in the PR—discussing the principles of resilient design and fault tolerance—YOU demonstrate deep expertise that goes far beyond simply making the code "work." This is how you build a reputation for excellence and drive your career forward.

2. Feed the Beast: Your Project's Context is its Fuel ⛽

AI coding assistants are incredibly powerful, but they aren't mind readers. They operate on a simple principle: garbage in, garbage out. If you give them a vague, one-line request, you'll get back a generic, probably useless, chunk of code. The secret to getting amazing results is to "feed the beast" with as much high-quality context as you possibly can.

Think of it like briefing a new developer on your team. You wouldn't just say, "Hey, go build the shipping cost feature." You'd give them the Jira ticket, point them to the requirements, explain the existing data models, and show them the acceptance criteria. You need to do the exact same thing for your AI partner.

This means going way beyond in-code comments. Give it the issue link, paste in the user story, and provide the Gherkin feature file if you have one. The more details you provide about the "what" and "why," the better the AI will be at generating the "how."

Technical Example: The Vague Wish vs. The Detailed Brief

Imagine you're tasked with implementing a dynamic shipping cost calculation based on a complex set of business rules.

The Vague Wish (and its useless result):

You start with a lazy prompt, giving the AI almost nothing to work with:

// TODO: Implement the shipping cost logic
// A vague prompt to the AI:
// "Java method to calculate shipping cost for an order"

The AI, having no context, will produce a generic, over-simplified method that is completely wrong for your application:

// AI's Generic (and wrong) Response:
public BigDecimal calculateShippingCost(Order order) {
    // A complete guess based on common, simple examples.
    BigDecimal baseRate = new BigDecimal("5.00");
    BigDecimal weightCharge = order.getWeightInKg().multiply(new BigDecimal("1.50"));
    return baseRate.add(weightCharge);
}

This code is a waste of time. It doesn't know about your business rules, your customer types, or your data structures. Now, let's try again by giving the AI a proper brief.

The Detailed Brief (and its awesome result):

This time, you treat the prompt like a mini-spec document, packing it with context right from your project.

/*
 * Feature: JIRA-451 - Calculate Dynamic Shipping Cost
 * * User Story: As a user, I want to see an accurate shipping cost at checkout
 * based on my membership status, location, and the items in my cart.
 *
 * Acceptance Criteria (from feature file):
 * - Prime members in the US get free shipping.
 * - Non-Prime US orders have a $5 flat fee.
 * - International orders have a 15% surcharge on the subtotal.
 * - Any order containing a 'HEAVY_GOODS' item has an additional $25 fee.
 *
 * Relevant Data Classes:
 * class User { boolean isPrimeMember(); Address getAddress(); }
 * class Order { List<LineItem> getItems(); BigDecimal getSubtotal(); }
 * class LineItem { Product getProduct(); }
 * class Product { ProductCategory getCategory(); } // enum ProductCategory { STANDARD, HEAVY_GOODS }
 *
 * AI Prompt:
 * "Using the context and data classes above, write a Java method `calculateShipping`
 * that takes a User and an Order and returns the final shipping cost as a BigDecimal."
 */

With this rich context, the AI can now generate something incredibly useful and specific to your actual codebase:

// AI's Context-Aware (and useful) Response:
public BigDecimal calculateShipping(User user, Order order) {
    // Rule 1: Prime members in the US
    if (user.isPrimeMember() && "US".equals(user.getAddress().getCountryCode())) {
        return BigDecimal.ZERO;
    }

    BigDecimal shippingCost;

    // Rule 2 & 3: US vs. International
    if ("US".equals(user.getAddress().getCountryCode())) {
        shippingCost = new BigDecimal("5.00"); // Flat fee for non-prime US
    } else {
        // 15% surcharge for international
        shippingCost = order.getSubtotal().multiply(new BigDecimal("0.15"));
    }

    // Rule 4: Surcharge for heavy goods
    boolean hasHeavyGoods = order.getItems().stream()
        .anyMatch(item -> item.getProduct().getCategory() == ProductCategory.HEAVY_GOODS);

    if (hasHeavyGoods) {
        shippingCost = shippingCost.add(new BigDecimal("25.00"));
    }

    return shippingCost;
}

Look at that difference! ✨ The second version is almost production-ready. It correctly implements the complex business logic because you gave the AI a map of your world. You spent an extra minute providing context and saved yourself thirty minutes of writing boilerplate and fixing the AI's guesses. That's a massive win.

Furthermore, this idea of creating rich context is expanding beyond just code and tickets. A whole ecosystem of specialized AI tools is emerging to help create and understand high-level documentation, which then becomes another powerful source of context.

MCP Servers can help to expand the capabilities of our AI Agents. Directories like mcp.so are great places to discover these. For instance, you can use a tool to connect to Jira to get information about the issues for a given feature, or even Google Docs to get formal and extended requirements definitions.

This information then serves as excellent context for your primary coding assistant, helping it understand the system's architecture when you ask it to write related code. This creates a virtuous cycle: you use AI to generate clear documentation, which in turn helps your coding AI generate better code.

3. Dodge the "Ball of Mud": Keep Your Code Maintainable 🧠

"Keep it simple" is easy advice to give, but in the real world of enterprise Java, it’s not so simple, is it? A 20-line method might be simple, but if you have a hundred of them in a tangled mess, you've created a classic "Big Ball of Mud" architecture. 👎

The real goal isn't just simplicity; it's maintainability. We want to write code that our future selves (and our teammates) can read, debug, and extend without wanting to tear their hair out.

AI assistants, for all their power, don't have a great sense of long-term consequences. They are fantastic at solving the immediate problem you give them, but they're not thinking about your architectural goals. They can, and will, generate overly clever, complex, or just plain weird code if you let them. Our job is to be the architect, not just the bricklayer, and guide the AI toward solutions that are easy to live with.

Technical Example: The "Clever" Stream vs. The Debuggable Loop

The Java Stream API is incredibly powerful, but it's also one of the easiest ways to write code that's "write-only." An AI, trained on millions of examples of functional programming, can get a little too excited about streams.

Imagine you need to process a list of new user signups. For each user, you need to check if they are eligible for a promo, send them a welcome email, and add them to a database, but only if they've verified their email.

You ask your AI: "// Java: using a stream, process this list of signups. Filter for verified users, check promo eligibility, send a welcome email, and save to the database. Return a list of the users who were successfully saved."

The AI might produce this "clever" one-liner:

// AI's "Clever" (but unmaintainable) Solution
public List<User> processSignups(List<SignUp> signups) {
    return signups.stream()
                  .filter(SignUp::isVerified) // Filter for verified users
                  .peek(signup -> { // DANGER: Side effects inside a stream!
                      boolean eligible = promoService.isEligible(signup.getEmail());
                      emailService.sendWelcomeEmail(signup.getEmail(), eligible);
                  })
                  .map(this::convertAndSaveUser) // This method handles the DB interaction
                  .collect(Collectors.toList());
}

private User convertAndSaveUser(SignUp signup) {
    User user = new User(signup.getName(), signup.getEmail());
    return userRepository.save(user);
}

This code is a maintenance nightmare. 😵

Debugging Hell: How do you debug this? If sendWelcomeEmail throws an exception for one user, the whole stream fails. You can't easily put a breakpoint inside the peek to inspect the state for a single user without getting swamped.
Hidden Side Effects: The peek operation is performing major side effects (sending an email!). This violates the functional principles that make streams great and makes the code incredibly hard to reason about.
Poor Readability: To understand the logic, you have to mentally unpack this dense chain of operations. It's not immediately obvious what's happening.

A developer focused on maintainability would see this and immediately refactor it into something more "boring," but infinitely more professional: a simple loop.

// Human-Crafted, Maintainable Solution
public List<User> processSignups(List<SignUp> signups) {
    List<User> successfullyProcessedUsers = new ArrayList<>();

    // A simple, "boring" loop is easy to read, easy to debug.
    for (SignUp signup : signups) {
        if (!signup.isVerified()) {
            continue; // Skip unverified users
        }

        try {
            // Each step is clear and explicit.
            boolean eligible = promoService.isEligible(signup.getEmail());
            emailService.sendWelcomeEmail(signup.getEmail(), eligible);

            User userToSave = new User(signup.getName(), signup.getEmail());
            User savedUser = userRepository.save(userToSave);
            successfullyProcessedUsers.add(savedUser);

        } catch (EmailException | DataAccessException e) {
            // We can handle errors for a single user without crashing the whole batch.
            log.error("Failed to process signup for email: {}", signup.getEmail(), e);
        }
    }
    return successfullyProcessedUsers;
}

This version is superior in every practical way. It's easy to read, you can stick a breakpoint anywhere you want, and the try-catch block provides robust, granular error handling. This same principle applies at a higher level. Resist the urge to let an AI push you toward an overly complex design like microservices when a well-structured monolith or a Hexagonal Architecture would be far more maintainable for your team's size and scope. Use AI as a tool, but you are the architect. Choose boring, maintainable solutions. Your future self will thank you. 🙏

4. Clean Your Room: No Stray Code or Sketchy Dependencies 🧹

Think of your AI assistant as a super-enthusiastic and brilliant, but slightly messy, collaborator. In its rush to build something cool, it might leave some tools out, grab a sketchy-looking part from a random website, or leave unused scraps of code lying on the floor.

Our job is to be the diligent cleaner who tidies up afterward. "Stray code" isn't just about unused imports or dead methods; it's about ensuring every single line in our project, including our build files, is there for a reason and comes from a trusted source.

Failing to do this isn't just sloppy—it can be a massive security risk. Modern software development is built on a mountain of dependencies, and AI can inadvertently lead us to pull a malicious one right into our project.

Technical Example: The AI's "Helpful" but Malicious Dependency

This is one of the most subtle and dangerous ways an AI can cause trouble. Let's say you need to add a feature to process and manipulate some complex XML files. You're not sure which library is best.

You ask your AI: "// I need to parse a complex XML file in Java. Suggest a good library and give me the Maven dependency for it."

The AI, having been trained on a vast amount of public code, including forum posts and GitHub issues with typos, might suggest this:

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-text-utils</artifactId> 
    <version>1.10.0</version>
</dependency>

You, the busy developer, glance at it. "org.apache.commons" looks legit, the name seems right, and you paste it into your pom.xml. You've just potentially opened the door to a typosquatting or dependency confusion attack. 💀

A threat actor could have published a malicious library to Maven Central under that slightly incorrect name (commons-text-utils instead of the real commons-text). Your build system would happily download it, and suddenly you have malware executing with full permissions inside your build environment or even in your production application.

The only safe habit is to never, ever trust a dependency string from an AI. Always do the 30-second check:

Open your web browser.
Go to Maven Central (search.maven.org) or the library's official GitHub page.
Search for the library and copy the official, verified dependency snippet.

What About Dead Code?

On a less dramatic but still important note, AIs often leave behind digital clutter. It might generate three helper methods but only end up using one in its final answer.

In Java, this isn't always a critical failure. An unused import is harmless. But an unused dependency in your pom.xml? That still gets bundled into your final JAR/WAR, bloating your application size. Worse, if you're using a framework like Spring with broad component scanning, a class from an "unused" dependency on the classpath could be auto-detected and wired into your application, causing truly baffling behavior.

The habit here is simple hygiene. Before you commit, run your IDE's code cleanup tools. Remove unused imports, variables, and methods. Use static analysis to flag unused dependencies. It's the digital equivalent of sweeping the workshop floor before you lock up for the night. It keeps your project lean, clean, and predictable. ✨

5. Trust but review: Analyze the AI, the Code, and the Supply Chain 🕵️‍♀️

Working with an AI is like getting advice from a brilliant expert who sometimes hallucinates. This is the core of my article "AI gives you TIME not CONFIDENCE.". The AI gives you a head start, but it doesn't give you a guarantee. To turn that AI-generated time into a reliable product, you have to practice healthy skepticism and analyze everything. This habit goes deeper than just checking the generated code; it involves scrutinizing the entire development ecosystem.

We must analyze three distinct areas:

The AI System Itself: Its limitations, its biases, and its security posture.
The Generated Code: Its correctness, its security, and its adherence to modern practices.
The Software Supply Chain: The third-party dependencies the AI suggests.

First, Analyze Your AI System

Before you even write a prompt, remember that the AI is not an oracle. It's a tool with known limitations.

Is Your Prompt Safe? 🔐 When you paste a chunk of your company's proprietary code into a free, public AI website, where does it go? You could be unintentionally leaking trade secrets. The habit is to use enterprise-grade, secure tools (like GitHub Copilot for Business or self-hosted options) that guarantee your code stays private.
Is your AI architecture secure? 👮When you use Agents and MCP servers, are you sure what they do? Have you checked their source code to know where your information goes?

Second, Analyze the Generated Code: Accuracy, Bugs, Security and Outdated Knowledge

This is where the rubber meets the road. Recent research confirms that while AI boosts speed, it comes with significant risks to quality and security.

The Sobering Reality of AI Accuracy

Don't fall for the marketing hype. A report from Sonar analysing top notch LLM models, revealed that although they produce a lot of good code, they have different levels of accuracy in their responses and are still incorporating issues and vulnerabilities. This means you must assume that any code generated by an AI is likely to be flawed in some way.

Security Vulnerabilities and Outdated Java Knowledge

LLMs can directly introduce vulnerabilities into the code they generate because their training data might contain insecure patterns, or they might make logical errors during generation that result in security flaws. For example, an LLM might generate SQL code without proper input sanitization or hardcoding secrets, leading to SQL injection vulnerabilities or credentials leak.

// DON'T PASTE THIS! ❌ It contains proprietary logic and sensitive keys.
// "Refactor this method to be more efficient"
public void processTransaction(Transaction tx) {
    if ("ProjectTitan".equals(tx.getProjectCode())) {
        String apiKey = "d3b07384d113edec49eaa6238ad5ff00"; // Hardcoded secret!
        var client = new ProprietaryBillingClient(apiKey);
        client.charge(tx.getAmount(), tx.getUserId());
    }
    // ... more confidential logic
}

Also an AI model might have a knowledge cutoff of early 2023. It knows nothing about the latest features in Java 21+. It will generate correct, but clunky and outdated code.

For example, you ask it to process different shapes. It might generate this pre-Java 21 code:

// AI's Outdated (pre-Java 21) solution
public double getArea(Shape shape) {
    if (shape instanceof Circle) {
        Circle c = (Circle) shape;
        return Math.PI * c.radius() * c.radius();
    } else if (shape instanceof Square) {
        Square s = (Square) shape;
        return s.side() * s.side();
    } else {
        return 0;
    }
}

A modern Java developer would immediately refactor this to a much cleaner and safer switch expression with type patterns:

// The Modern Java 21+ Solution
public double getArea(Shape shape) {
    return switch (shape) {
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Square s -> s.side() * s.side();
        default -> 0;
    };
}

Third, Analyze the Dependencies (The Software Supply Chain)

This is where things get really serious. An AI might suggest a cool, niche library to solve your problem. Here's your analysis checklist before you ever add it to your pom.xml.

1. Is it Well-Maintained?

You ask an AI for a CSV parsing library. It might suggest a once-popular but now-abandoned option , like *net.sf.supercsv:super-csv* discontinued in 2015.

2. Is it Properly Licensed?

Accidentally using the wrong license can create a legal nightmare for your company. An AI won't warn you if a library is AGPL-licensed.

The Threat: An AI suggests a library for charting. You add it to your pom.xml, not realizing it has a restrictive license that could force you to open-source your proprietary product.
The Habit: You must check the license. Use automated tools like the SonarQube or OWASP Dependency-Check plugin for Maven/Gradle, among others, which can automatically scan your dependencies and flag license conflicts based on policies you define.

3. Are There Known Vulnerabilities?

Even if a library is well-maintained and properly licensed, older versions (or even the latest) might have publicly reported security vulnerabilities.

The Threat: An AI suggests jackson-databind version 2.9.0. You add it, unaware that this version has a critical deserialization vulnerability (CVE-2017-7525) that attackers could exploit to execute arbitrary code.
The Habit: This is the most crucial check. You must scan your dependencies for known vulnerabilities. Tools like SonarQube*,* integrate with your build process and continuously monitor your dependencies against public vulnerability databases (like the National Vulnerability Database - NVD) to alert you of potential issues. Regularly updating your dependencies is also key.

Analyzing your dependencies is a non-negotiable part of a professional developer's job. The AI is just a recommender; you are the gatekeeper. ✅

**6. Beyond Coverage: Mandate Meaningful Tests ✅**

For years, we've been told to chase the holy grail of 100% code coverage. But as you astutely noted, that's often a vanity metric. A suite of heavily mocked unit tests that covers every line of code can still completely miss the point. The real goal of testing isn't to cover code; it's to build confidence that your software correctly solves a real-world business problem.

AI is a game-changer for testing, but it can also lead you down the wrong path if you're not careful. It's brilliant at generating boilerplate, but it has no understanding of your business intent. The modern testing habit is to use AI as a tireless assistant for the simple stuff, freeing up your valuable brainpower to design the high-level tests that truly matter.

AI for the Easy Stuff: Boilerplate Unit Tests

Let's be clear: AI is fantastic at generating simple unit tests for pure functions or utility classes. You can point it at a class and say, "Generate JUnit 5 tests for this," and it will save you a ton of tedious work.

But here's the trap we discussed in the last habit: if the AI wrote the buggy code, it will happily write a test that confirms the bug, giving you a beautiful "green" test suite that is actively lying to you.

// AI wrote this buggy method...
public String truncate(String text, int length) {
    // BUG: Off-by-one error. Should be <= length
    if (text.length() < length) { return text; }
    return text.substring(0, length - 1) + "...";
}

// ...and the AI will gladly write a test that confirms the bug.
@Test
void testTruncation() {
    String result = truncate("hello world", 5);
    // DANGER: The AI asserts the incorrect result it expects.
    assertEquals("hell...", result); // This passes! 😱
}

The habit: Use AI for boilerplate, but you, the human, must write the critical assertions based on the requirements, not based on the code's current behavior.

The Human's Job: Integration Tests That Build Real Confidence

True confidence comes from watching your code interact with real infrastructure. This is where you should focus your energy. Stop over-mocking and start writing real integration tests.

The Wrong Way (Useless Mocking): Many developers test their service layer by mocking the database repository. This is a low-value test.

// This test proves almost nothing.
@Test
void testUserServiceWithMock() {
    // 1. Setup the mock
    UserRepository mockRepo = mock(UserRepository.class);
    when(mockRepo.findByStatus("ACTIVE")).thenReturn(List.of(new User("Jon")));

    // 2. Call the service
    UserService userService = new UserService(mockRepo);
    List<User> activeUsers = userService.findActiveUsers();

    // 3. Assert
    // This only checks if your service called the mock. It tells you NOTHING
    // about whether your actual @Query works, if your DB schema is correct,
    // or if transactions behave as expected.
    assertEquals(1, activeUsers.size());
    verify(mockRepo).findByStatus("ACTIVE");
}

The Right Way (Real Confidence with Testcontainers): A professional Java developer uses tools like Testcontainers to spin up a real database for the test.

// This test builds REAL confidence.
@SpringBootTest
@Testcontainers
class UserServiceIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15-alpine");

    // Spring Boot will automatically configure the app to use this database.
    @DynamicPropertySource
    static void configure(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Autowired
    private UserService userService;

    @Autowired
    private UserRepository userRepository;

    @Test
    void findsOnlyActiveUsersFromRealDatabase() {
        // 1. Setup REAL data in a REAL database
        userRepository.save(new User("Jon", "ACTIVE"));
        userRepository.save(new User("Jane", "INACTIVE"));

        // 2. Call the service
        List<User> activeUsers = userService.findActiveUsers();

        // 3. Assert
        // This test proves your @Query, schema, and service logic all work together.
        assertEquals(1, activeUsers.size());
        assertEquals("Jon", activeUsers.get(0).getName());
    }
}

The Ultimate Collaboration: AI-Powered Acceptance Tests

Here's where it all comes together. Your Product Owner or a domain expert writes the requirements in a plain-text Gherkin file. This file becomes the ultimate source of context.

Gherkin login.feature file (written by a human):

Feature: User Login

  Scenario: Successful login with valid credentials
    Given I am on the login page
    When I enter "jon.doe" as my username
    And I enter "a-valid-password" as my password
    And I click the login button
    Then I should be redirected to my dashboard page

Now, you use this as context for your AI. The habit: Ask the AI to be a translator. "Given this Gherkin feature, generate the boilerplate Java step definitions for Cucumber."

AI-Generated Java "Glue Code" (a huge time-saver):

// AI generates this skeleton code for you instantly.
public class LoginSteps {
    @Given("I am on the login page")
    public void i_am_on_the_login_page() {
        // TODO: Implement browser navigation logic here
        throw new io.cucumber.java.PendingException();
    }
    @When("I enter {string} as my username")
    public void i_enter_as_my_username(String username) {
        // TODO: Implement selenium/playwright logic here
        throw new io.cucumber.java.PendingException();
    }
    // ... and so on for the rest of the steps.
}

The AI handles the tedious mapping, and you focus on implementing the meaningful automation logic. You're not just testing code anymore; you're verifying business requirements directly. And if you want to be extra sure your tests are good, look into mutation testing (e.g., with Pitest) to see if your test suite can actually catch bugs.

7. The Human Gateway: A Code Review for What AI Can't See 🧠

Let's get one thing straight: automated code reviewers and SAST tools are fantastic. They are tireless defenders against simple bugs, style violations, and common security flaws. Let the machines handle that stuff. That is their job now.

Modern platforms like SonarQube, with its "AI Code Assurance" feature, are evolving to specifically address code generated by AI. They can help maintain quality and consistency, acting as the first line of defense even for machine-generated code, ensuring that the human reviewer's focus remains on higher-order concerns.

This frees up human code reviews to be what they were always meant to be: a high-level conversation about the thinking behind the code. The Pull Request (PR) is no longer a gate for catching typos; it's a forum for sharing knowledge, questioning assumptions, and ensuring the solution truly aligns with the business domain and our long-term architectural vision.

Your role as a reviewer has been upgraded. You are no longer a human linter; you are a design partner and a knowledge steward.

Focus on What Only a Human Can Judge

When you open a PR in this new world, you can skip the stuff an automated tool can find. Instead, you focus your valuable brainpower on these questions:

Does it actually solve the business problem? 🧠 An AI doesn't understand the nuances of your company's new return policy or the legal requirements of a GDPR data request. Does the code really do what the JIRA ticket asked for, including the unwritten assumptions?
Is this a maintainable design? 🏗️ The code might work today, but will a junior developer understand it in six months? Is this a quick fix that adds to our technical debt, or a solid, long-term solution that fits our architecture (e.g., Hexagonal, DDD)?
What are the hidden edge cases? ⛈️ Based on your experience, what could go wrong? What happens if a downstream API times out? What if the input list is empty? What if a user's name contains weird characters? Humans are great at this kind of "what-if" analysis.
Is it a good opportunity to mentor? 🌱 A PR is one of the best places to share knowledge. It's a chance to explain a design pattern, suggest a better way to handle an error, or introduce a teammate to a more modern library or language feature.

Example: A Conversation, Not a Judgment

Imagine a developer used an AI to implement a caching layer for a frequently called service. The code is clean and the automated checks all pass. ✅

The old way of reviewing might be a simple "LGTM" (Looks Good To Me).

The new way of reviewing is a collaborative conversation that shares knowledge and improves the design.

Here's the code snippet in the PR:

// service/ProductService.java
import com.google.common.cache.Cache;
import com.google.common.cache.CacheBuilder;

@Service
public class ProductService {
    // An in-memory cache for product details
    private final Cache<Long, ProductDetails> productCache = CacheBuilder.newBuilder()
        .maximumSize(1000)
        .expireAfterWrite(10, TimeUnit.MINUTES)
        .build();

    public ProductDetails getProductDetails(long productId) {
        // AI correctly implemented the cache-aside pattern
        return productCache.get(productId, () -> repository.findDetailsById(productId));
    }
}

And here's the human-centric review in the PR comments:

Senior Dev: "Hey, great job getting the caching logic in here! The AI did a nice job with the Guava cache implementation. It's super clean. 👍"

"I have one architectural question for us to think about. This is an in-memory cache, which is perfect for a single instance. What do you think will happen when we deploy this to our production environment, which runs 3 instances of this service for high availability?"

"The risk is that the caches could get out of sync. An admin might update a product's details, and that request might hit instance A, updating its cache. But instances B and C would still be serving the old, stale data for up to 10 minutes."

"This might be a good opportunity for us to introduce a distributed cache like Redis. It would solve the consistency problem and give us a centralized place to manage our caching strategy. It's a bigger change, but it would make our system much more robust. What are your thoughts on that approach? No pressure to do it in this PR, but let's discuss it. 🤔"

This review accomplishes everything a human review should. It validates the work, shares deep knowledge about distributed systems, prevents a future production issue, and does it all in a collaborative, respectful way. This is a conversation AI can't have. This is where we, the humans, provide the real value.

Conclusion: Your AI Co-Pilot Needs a Safety Net 🚀

The age of AI-assisted development isn't about replacing developers; it's about upgrading them.

The seven habits we've explored are a roadmap for moving beyond being a simple "user" of AI to becoming a skilled craftsperson who wields it with intention and wisdom. It’s about taking pride in your work, providing deep context, demanding maintainability, practicing good hygiene, scrutinizing everything, writing tests that matter, and keeping the human element at the heart of your reviews.

Cultivating these habits is a conscious effort, but you don't have to do it alone. While you focus on high-level design and business logic, you need a safety net to catch the subtle mistakes, security vulnerabilities, and bad practices that AI can introduce into your code. This is where having an automated code quality and security toolset becomes non-negotiable.

That's why you should check out the Sonar solution. By adding SonarQube IDE extension(IntelliJ, VS Code, etc.), you get real-time feedback on the code as it's generated, catching bugs and vulnerabilities before they're even committed. Then, by connecting it to SonarQube Cloud, your entire team gets a shared understanding of the project's health, ensuring that what you ship is not just functional, but truly with high quality and security. Think of it as the perfect third partner in your development process: your skill, the AI's speed, and Sonar's safety.

Building a Secure Fortress within AI: A Developer's Guide to Full-Stack Security 🏰

Jonathan Vila — Wed, 17 Sep 2025 16:40:39 +0000

Hey developers! 👋 Do you ever feel like you're constantly rushing to build new features, fix bugs, and keep up with the latest tech? That's a lot, right? And now, powerful tools like Generative AI are here to help us accelerate even more. But this new age of development brings a unique set of challenges, especially for security.

With all this pressure to move fast, security can feel like the first thing to get pushed aside. But what if it didn't have to be a chore? This article is about making security a natural, easy part of your daily coding—an automated safety net that ensures everything you build, whether by hand or with AI, is secure from the start. Let's make security a superpower we all have! 💪

What we'll cover

The rise of AI code generation: How AI tools are changing development and why this makes security analysis more important than ever.
SAST (Static Application Security Testing): Finding security bugs in your own code before it even runs.
Advanced SAST: Discovering hidden vulnerabilities that result due to interaction of first-party code with third-party open source libraries.
Secrets detection: Keeping sensitive keys and passwords out of your source code.
IaC (Infrastructure as Code) analysis: Checking your configuration files for issues.
SCA (Software Composition Analysis): Managing risks in your open source dependencies.

1. Why security matters: Lessons from the real world

We all know the pressure: "Get it done yesterday!" In this race, security often gets pushed to the side. But here's the thing: finding a security problem when your application is already in production is like trying to fix a leaky roof during a storm. It's expensive, stressful, and usually a mess. 😱

This is why we talk about "Shift-Left" security. It just means finding and fixing issues early in the development process. The cost of not shifting left can be enormous, as some of the biggest names in tech have learned the hard way.

Apache Struts vulnerability (2017) One of the most damaging breaches in history was caused by a vulnerability in a third-party framework (Apache Struts). This is a classic, painful lesson in the importance of Software Composition Analysis (SCA), which we'll cover in Section 4. (Read more about the breach).
The Log4Shell vulnerability (2021): This zero-day vulnerability in a popular Java logging library, Log4j, sent shockwaves through the tech world. It perfectly illustrates how a single flaw in an open-source dependency can have a global impact, reinforcing the need for both SCA and advanced SAST. (Read more about Log4Shell).
Missconfigured IaC (2019): This breach, which exposed the data of over 100 million customers, was a result of a misconfigured web application firewall. This highlights why Infrastructure as Code (IaC) Analysis is no longer optional. (Read more about the incident).

These aren't just stories; they are cautionary tales that show how the small details in our code and configurations can have massive consequences.

2. A new challenge: The age of AI-generated code 🤖

There's a new player in our daily workflow: Generative AI. Tools like GitHub Copilot are incredible productivity boosters, helping us write boilerplate, solve complex problems, and learn new patterns. But with great power comes great responsibility. The code generated by these AI assistants is not perfect. In fact, it's trained on massive datasets of public code—which includes both good and bad patterns.

This means AI can, and often does, generate code that contains subtle security vulnerabilities or introduces technical debt. Research supports this: a study led by Stanford University found that developers who used AI assistants were significantly more likely to produce insecure code.

Another analysis of popular LLMs used by AI code generation, done by Sonar, found that more than 60% of the security issues of AI-generated code suggestions were Blockers (Read the full report here).

This doesn't mean we should stop using AI. It means that as we accelerate code production, having a robust, automated security safety net is more critical than ever. The tools and techniques we're about to discuss act as that essential quality gate, ensuring the code—whether written by a human or an AI—is secure before it reaches production.

3. Securing our code: The core foundation 🕵️‍♀️

Let's start with the code in our project, regardless of who (or what) wrote it.

SAST (Static Application Security Testing): Think of SAST as your vigilant code reviewer. It scans your source code for common vulnerabilities like SQL Injection. For example, a SAST tool would immediately flag this Python code because it uses an f-string to build a query, which is unsafe.

# 👎 BAD - Vulnerable to SQL Injection
username = request.args.get('username')
query = f"SELECT * FROM users WHERE username = '{username}'" # Unsafe!
cursor.execute(query)

The fix is to use parameterized queries, which separate the command from the data.

# 👍 GOOD - Safe from SQL Injection
query = "SELECT * FROM users WHERE username = %s"
cursor.execute(query, (username,))

Taint analysis & advanced SAST: Taint Analysis is a smart type of SAST that tracks dangerous user input. Advanced SAST takes this a step further. Traditional SAST often treats third-party libraries like a "black box." It sees your code call a library function, but it doesn't look inside that function to see what happens next. Advanced SAST is dependency aware SAST that analyzes the interaction between your code and your dependencies, finding hidden flaws. Consider this JavaScript example using the fs-extra library:

// User input from a request, e.g., "../../../etc/passwd"
app.get('/readfile', (req, res) => {
  const targetDirectory = "/data/app/resources/";
  const userFilename = path.join(targetDirectory, req.query.filename);

  let data = fs.readFileSync(userFilename, { encoding: 'utf8', flag: 'r' });
  res.send(data);
});

An advanced SAST analysis knows that the readFileSync function can create directories, leading to a Path Traversal vulnerability. It finds security issues or vulnerabilities that are hidden deep inside your opensource dependencies. 🔴➡️📦➡️🛡️
Secrets detection: We've all been there, right? You're rushing, and suddenly, an API key ends up committed to your Git repository. 🤦‍♂️ Secrets detection tools scan your code for these slip-ups. A tool would immediately flag a hardcoded secret like this:

// 👎 BAD - Hardcoded secret
const config = {
  apiKey: "super-secret-key-123456789-abcdefg", // Leaked key!
};

Infrastructure as Code (IaC) analysis: As we saw with the Capital One case, misconfigurations can be disastrous. IaC analysis scans configuration files for these issues. For example, this Dockerfile has two common security flaws:

# 👎 BAD - Insecure Dockerfile
FROM ubuntu:latest
USER root      # 1. Running as the root user is risky
EXPOSE 22     # 2. Exposing the SSH port is dangerous
COPY . /app
CMD ["run_app"]

4. Securing our dependencies: The software supply chain 🌍

As the Equifax and Log4Shell incidents proved, our applications are only as secure as the open-source libraries they are built on. This is where Software Composition Analysis (SCA) comes in. SCA tools analyze your dependency files (like package.json or pom.xml) to give you a clear picture of your supply chain risk.

Vulnerability (CVE) detection: The most obvious task of SCA is to check your libraries against a database of known vulnerabilities (CVEs). An SCA tool would scan the pom.xml below and immediately flag jackson-databind because version 2.9.8 has multiple critical remote code execution vulnerabilities. 🚨

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.5.4</version>
    </dependency>

    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>2.9.8</version> 
    </dependency>
</dependencies>

This instant feedback allows you to patch the vulnerability by upgrading the dependency version, long before it becomes a problem in production.
Why License checks are critical: "Open source" doesn't mean "no rules." Accidentally using a library with the wrong license can create huge legal and intellectual property risks for your company. An SCA tool analyzes all direct and transitive dependencies and reports on their licenses, comparing them against your policies. The output might look something like this:

--- License Check Report ---
Policy: Forbid 'copyleft' licenses (GPL, AGPL)

[ INFO ] spring-boot-starter-web-2.5.4.jar: (Apache-2.0) -> OK
[ INFO ] jackson-databind-2.9.8.jar: (Apache-2.0) -> OK
[ VIOLATION ] gpl-library-1.2.3.jar: (GPL-3.0) -> FORBIDDEN
...

This automated check is essential for avoiding "copyleft" licenses like the GPL that could legally obligate you to make your own proprietary source code public.
SBOM: Your application's essential "Ingredients List": A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component in your application. An SBOM tool reads your pom.xml, resolves the entire dependency tree, and generates this list. Here is a small, simplified example of what part of an SBOM file (in CycloneDX format) looks like:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "component": { "type": "application", "name": "my-cool-app" }
  },
  "components": [
    {
      "type": "library",
      "name": "jackson-databind",
      "version": "2.9.8",
      "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.8"
    }
    // ... hundreds of other dependencies would be listed here
  ]
}

This inventory is critical for vulnerability management and is quickly becoming a legal requirement. The U.S. government's Executive Order 14028 and the European Union's Cyber Resilience Act (CRA) are making SBOMs mandatory for selling software in major markets.

5. The challenge: Avoiding "Tool Sprawl" 🧩

So, we have all these important security checks. The obvious first step might be to grab a separate open-source or commercial tool for each job: one for SAST, another for SCA, a third for secrets, and so on. But this approach, known as "tool sprawl," quickly creates a new set of problems that hurt developer productivity.

Unaggregated reports and alert fatigue: You get SAST alerts in your CI/CD logs, SCA vulnerability reports in your email, and IaC issues on another dashboard. The data is scattered everywhere. It's impossible to get a single, clear picture of your application's security posture, and developers become overwhelmed by alerts from too many sources.
Lack of integration and context: These separate tools don't talk to each other. A vulnerability in your code (found by SAST) might be exploitable only because of a specific library version (flagged by SCA). Without an integrated view, you lose this critical context, making it harder to prioritize and fix the most important issues first.
High maintenance overhead: If you're managing these tools on-premise, each one is a new application to maintain. Every tool needs its own deployment, configuration, user management, and regular updates. Your teams can end up spending more time managing the security tools than actually using them to fix security issues.

This "tool sprawl" creates noise, friction, and ultimately slows development down. The ideal solution is a single, integrated platform that unifies all these capabilities.

6. A practical solution & your next step 🚀

So, how can you get that integrated, clear, and actionable view of your application's security? This is where a powerful tool like SonarQube Cloud comes in, especially with the latest addition of the Advanced Security (available as a subscription) feature including all the points touched previously. It's built specifically to solve the "tool sprawl" problem by showing you how all these concepts come together in a real-world workflow.

Here’s a glimpse of how SonarQube Cloud brings all the capabilities we've discussed to life:

A unified view of your project's health: Instead of scattered reports, you get a single dashboard that gives you a clear overview of your project's health. It combines code quality metrics, security vulnerabilities from your code, and risks from your dependencies all in one place. This immediately tells you if your project is ready for release or needs attention.

[Screenshot 1a: The main SonarQube dashboard showing a project's overall quality gate status, with clear metrics for vulnerabilities, bugs, and security hotspots.]

[Screenshot 1b: The SonarQube Security report showing a project's overall security issues grouped by Category and showing the CVE associated.]

Actionable advanced SAST findings: When a vulnerability is found in your code, you get more than just a line number. The tool explains why it's a vulnerability, shows the full data flow for complex taint analysis issues, and provides rich examples and guidance on how to fix it properly. This turns a simple finding into a learning opportunity.

[Screenshot 2: A detailed SonarQube issue view, showing the highlighted vulnerable code, a clear explanation of the risk (e.g., SQL Injection), and the full taint analysis path from source to sink.]

Clear SCA and supply chain insights: You can see a clear, prioritized list of all your third-party dependencies with any detected CVEs and License violations. The interface shows you the severity of the vulnerability and whether a safe, upgraded version is available, making it easy to manage risks like Log4Shell.

[Screenshot 3a: The SonarQube SCA view listing vulnerable dependencies, their CVEs, severity levels, and available upgrade versions.]

[Screenshot 3b: The SonarQube CVE view showing the different library versions partially or completely fixing the vulnerability.]

[Screenshot 3c: The SonarQube Dependency Risks view showing the licensing issues we suffer with the current dependencies]

Integrated secrets and IaC analysis: Hardcoded secrets and IaC misconfigurations aren't treated as separate, isolated problems. They are flagged and reported right alongside your other code issues, directly within your pull request or branch analysis. This ensures these critical issues are never missed before they reach production.

[Screenshot 4: A SonarQube issue view showing a newly introduced container image without version or tag in a Dockerfile]

By presenting all these issues directly in your CI/CD pipeline, SonarQube Cloud makes security a natural part of the development workflow. It helps you fix issues early, before they even get merged, and reduces the noise so you can focus on building great, secure software.

The best way to truly understand the power of this integrated approach is to see it work on your own code.

SonarQube Cloud is free for open-source projects, and for private projects under 50K lines of code. It's super easy to set up with your existing GitHub, GitLab, Bitbucket, or Azure DevOps repository. You can get your first analysis in minutes!

Want to use Java 22, 23 and 24 features safely ? This article will give you tips and checks that will help you on the way.

Jonathan Vila — Fri, 11 Jul 2025 17:16:30 +0000

Jonathan Vila

Jul 11 '25

Java 22 to 24: Level up your Java Code by embracing new features safely

#programming #java #codequality

Comments

15 min read

Java 22 to 24: Level up your Java Code by embracing new features safely

Jonathan Vila — Fri, 11 Jul 2025 17:13:47 +0000

Java introduces several new language features in the 22 to 24 versions which collectively simplify code, enhance documentation, and provide powerful tools for bytecode manipulation and advanced stream processing. This article shows you how to leverage these new features with simple examples.

Understanding these new features in Java is crucial for writing updated, efficient, and high quality code. To assist developers in adopting these changes correctly, SonarQube has introduced several new rules designed to check for the proper usage of unnamed variables and patterns, javadoc and markdown, Class-file new API and Stream gatherers, ensuring your code adheres to best practices and avoids common pitfalls.

We’ll cover several new Java features, with new rules in SonarQube:

Java 22 : Unnamed variables
Java 23 : JavaDoc and Markdown
Java 24 : Class-File API and Stream Gatherers

Java 22: Unnamed variables and patterns

A significant and welcome addition in Java 22 is the finalization of unnamed variables and patterns, officially detailed in JEP 456. This feature enhances code clarity by allowing developers to use an underscore (_) for variables and patterns that are intentionally left unused.

This elegantly addresses common scenarios where a variable is required by syntax but has no relevance to the business logic, such as a caught exception object that is never inspected or a loop variable in an enhanced for-loop where only the iteration count matters.

By replacing these placeholder names with a simple underscore, developers can reduce code clutter, eliminate "unused variable" warnings, and more clearly express their intent. This ultimately leads to higher-quality,more maintainable Java code.

SonarQube introduces a suite of new rules to ensure proper adoption of Java 22's unnamed variables and patterns. These rules — including S7466, S7467, and S7475 — guide developers in leveraging this feature for more maintainable code. Adhering to these guidelines enables teams to significantly improve code clarity and address redundant warnings.

Rule S7466: Unnamed variable declarations should use the `var` identifier

When declaring an unnamed variable, the type declaration often becomes redundant. The primary purpose of an unnamed variable is to signal that it won't be used, making its specific type less critical. Using var in this context enhances conciseness and maintains focus on the intent: to intentionally ignore the variable.

Let's look at an example. When iterating over a collection where only the number of iterations matters, the element itself is not used.

Noncompliant Code Example:

int count = 0;
for (String element : myList) { // "element" is unused
    count++;
}

In Java 22, you can use an unnamed variable. However, explicitly declaring the type is unnecessary.

Noncompliant Code Example:

int count = 0;
for (String _ : myList) { // The type "String" is redundant
    count++;
}

This is where rule S7466 comes in, suggesting a cleaner, more concise approach.

Compliant Solution:

int count = 0;
for (var _ : myList) {
    count++;
}

By using var, the code becomes less verbose and the intent remains clear.

Rule S7467: Unused exception parameters should use the unnamed variable pattern

A common scenario in Java is catching an exception where the exception object itself is not needed. Previously, developers would have to declare the exception variable, even if it was never referenced, leading to "unused variable" warnings from static analysis tools. Java 22's unnamed variables provide a perfect solution for this.

Consider a try-catch block where the simple fact that an exception was caught is enough, and its details are irrelevant.

Noncompliant Code Example:

try {
    // some operation that might throw an exception
} catch (NumberFormatException e) { // "e" is unused
    // log that the format was invalid
}

While functional, the declaration of e is noise. Using an unnamed variable is a better approach, and this is what SonarQube now recommends.

Compliant Solution:

try {
    // some operation that might throw an exception
} catch (NumberFormatException _) {
    // log that the format was invalid
}

This compliant solution is cleaner and explicitly communicates that the exception object itself is not important for the handling logic.

Rule S7475: Types of unused record components should be removed from pattern matching

Record patterns, a powerful feature for deconstructing record instances, are also enhanced by unnamed patterns. When pattern matching against a record, you might only be interested in a subset of its components. With unnamed patterns, you can ignore the components you don't need.

When an entire record component is unused in a pattern match, specifying its type is superfluous. Rule S7475 encourages the removal of these unnecessary type declarations, leading to more readable and less cluttered code.

Imagine you have a ColoredPoint record and you only need the Point component in your logic.

Noncompliant Code Example:

if (obj instanceof ColoredPoint(Point p, Color c)) { // "c" is unused
    // logic that only uses p
}

In Java 22, you can use an unnamed pattern for the Color component. However, including the type is not necessary if the component is completely ignored.

Noncompliant Code Example:

if (obj instanceof ColoredPoint(Point p, Color _)) { // The type "Color" is redundant
    // logic that only uses p
}

The most concise and readable version, as enforced by SonarQube, omits the type for the unused component entirely.

Compliant Solution:

if (obj instanceof ColoredPoint(Point p, _)) {
    // logic that only uses p
}

This approach makes the code more focused on the relevant data, improving maintainability.

Java 23: JavaDoc and Markdown

Java 23 introduces an enhancement to JavaDoc, allowing comments that begin with three slashes ///\ to be interpreted as JavaDoc comments using Markdown syntax. This subtle yet significant change aims to simplify the process of writing rich and readable documentation directly within the code. By leveraging Markdown, developers can more easily format their JavaDoc comments with features like bold text, italics, lists, and code blocks, without needing to learn specific JavaDoc HTML tags, officially detailed in JEP 445. This streamlines the documentation process, making it more intuitive and encouraging the creation of better-formatted and more accessible API documentation.

SonarQube has introduced new rules to assist developers in adopting Java 23's Javadoc and Markdown enhancements. These rules — including S7476 and S7474 — ensure that documentation is consistently formatted, easy to read, and free from common migration pitfalls. By leveraging these rules, developers can seamlessly integrate Markdown into their Javadoc comments to improve clarity and maintainability, ensuring that the old code is completely aligned with the new features.

Rule S7476: Comments should not start with more than two slashes

With Java 23, comments starting with /// are now officially interpreted as Javadoc comments that use Markdown syntax. Before, they were simply ignored by the Javadoc tool and treated as regular implementation comments. This change means that existing comments in your codebase could unintentionally become part of your public API documentation after migrating to Java 23. This can lead to confusing or unprofessional-looking documentation and increases the effort required for migration. This new rule helps you find these cases in advance so they can be corrected.

Noncompliant Code Example:

public class Calculator {

  /////////////////////////////////////////////
  // A section for advanced math operations. //
  // These are experimental.                 //
  /////////////////////////////////////////////
  public int add(int a, int b) {
    /// This is a super important implementation note for the add method.
    /// It should not be in the final Javadoc.
    return a + b;
  }
}

In the example above, both the decorative block comment and the /// comment would be incorrectly processed as Javadoc in Java 23. Compliant Solution:

public class Calculator {

  // A section for advanced math operations.
  // These are experimental.
  public int add(int a, int b) {
    // This is a super important implementation note for the add method.
    // It should not be in the final Javadoc.
    return a + b;
  }
}

The compliant solution is to ensure regular comments use the standard `//` syntax.

Rule S7474: Markdown, HTML and Javadoc tags should not be mixed

Java 23's introduction of Markdown in Javadoc comments is a significant step towards cleaner, more readable documentation. To maintain consistency, it's best to fully embrace Markdown syntax and avoid mixing it with legacy HTML tags (like <b>, <code>, <li>) or old Javadoc block tags (like {@code} or {@link}). Mixing these styles can lead to inconsistent rendering across different tools and makes the raw documentation harder to read. This rule encourages developers to use the modern, more concise Markdown syntax wherever possible.

Noncompliant Code Example:

///
/// A utility class for <b>String</b> operations.
/// <p>
/// Use this class to perform common manipulations. For more details,
/// see {@link java.lang.String}.
/// You can also use {@code new StringManipulator()}.
///
public class StringManipulator {
  // ...
}

This Javadoc mixes bold HTML tags with Javadoc's {@link} and {@code} tags. The clean, modern approach is to use Markdown for all formatting.

Compliant Solution:

///
/// A utility class for **String** operations.
///
/// Use this class to perform common manipulations. For more details,
/// see [String].
/// You can also use `new StringManipulator()`.
///
public class StringManipulator {
  // ...
}

By adopting a consistent Markdown style, your documentation becomes cleaner, easier to write, and future-proof.

Java 24 : Class-File API

Java 24 introduces the Class-File API (JEP 457), a significant enhancement for parsing, generating, and transforming Java class files. This API provides a programmatic way to work with class files at a low level, offering more flexibility and control than existing bytecode manipulation libraries. It's particularly beneficial for tools that perform static analysis, bytecode instrumentation, or code generation, enabling them to operate directly on the structured representation of class files. By standardizing this access, the Class-File API simplifies development for such tools and ensures greater compatibility across different Java versions.

SonarQube provides a new set of rules to help developers effectively utilize the Class-File API. These rules — including S7479, S7477, and S7478 — are designed to ensure that you use the API efficiently and correctly, leading to more concise, readable, and maintainable bytecode generation and transformation code. Adhering to these guidelines helps developers avoid common pitfalls and leverage the full potential of Java 24's Class-File API.

Rule S7479: `withMethodBody` should be used to define methods with a body

The new Class-File API (JEP 484) provides a standardized and flexible way to programmatically generate and modify Java class files. When building a class, the ClassBuilder API offers two similar methods for adding a method: withMethod and withMethodBody.

While both can achieve the same result, withMethod is a general-purpose tool that requires an extra step to define the method's code via a nested methodBuilder. For the common case of defining a non-abstract method with a body, the withMethodBody method is a more direct and efficient choice. It reduces boilerplate code, lowers cognitive complexity by removing a layer of nesting, and ultimately improves the maintainability of your class-generation code.

This rule encourages replacing withMethod with its more concise counterpart, withMethodBody, whenever you are defining a method that has a concrete implementation.

Noncompliant Code Example:

ClassBuilder addMethod(ClassBuilder builder) {
    return builder
        .withMethod("foo", MTD_void, ACC_PUBLIC | ACC_STATIC, methodBuilder -> { // Noncompliant
            methodBuilder.withCode(codeBuilder ->
                codeBuilder.getstatic(ClassDesc.of("java.lang.System"), "out", ClassDesc.of("java.io.PrintStream"))
                    .ldc("Hello World")
                    .invokevirtual(ClassDesc.of("java.io.PrintStream"), "println", MTD_void)
                    .return_()
            );
        });
}

This code uses withMethod, which introduces a methodBuilder. This then requires a call to withCode and an additional nested lambda (codeBuilder -> ...) just to define the method's body, making the code unnecessarily verbose.

Compliant Solution:

ClassBuilder addMethod(ClassBuilder builder) {
    return builder
        .withMethodBody("foo", MTD_void, ACC_PUBLIC | ACC_STATIC, codeBuilder ->
            codeBuilder.getstatic(ClassDesc.of("java.lang.System"), "out", ClassDesc.of("java.io.PrintStream"))
                .ldc("Hello World")
                .invokevirtual(ClassDesc.of("java.io.PrintStream"), "println", MTD_void)
                .return_()
        );
}

The compliant solution uses withMethodBody, which directly accepts the code-building lambda. This removes the intermediate methodBuilder, resulting in flatter, more readable, and more maintainable code that clearly expresses the intent of defining a method and its body in a single, streamlined operation.

Rule S7477: The simpler `transformClass` overload should be used when the class name is unchanged

The Class-File API, introduced in Java via JEP 484, provides powerful methods for transforming class files. Among these is the transformClass method, which comes in several overloaded versions to handle different use cases.

A common scenario is transforming a class without changing its name. For this specific situation, the API provides a concise two-argument version of transformClass. Using the more complex, three-argument overload and manually passing the original class name is unnecessary.

This rule encourages using the simplest possible API to make code shorter, clearer, and less prone to error. By choosing the correct transformClass overload, you explicitly signal that the class is not being renamed, which improves the overall readability and maintainability of the code.

Noncompliant Code Example:

public static void transformClassFile(Path path) throws IOException {
    ClassFile classFile = ClassFile.of();
    ClassModel classModel = classFile.parse(path);
    byte[] newBytes = classFile.transformClass(classModel,
      classModel.thisClass().asSymbol(), // Noncompliant: This argument is redundant
      (classBuilder, classElement) -> {
        if (!(classElement instanceof MethodModel methodModel &&
            methodModel.methodName().stringValue().startsWith("debug"))) {
            classBuilder.with(classElement);
        }
      });
}

In this example, the class name is explicitly passed to transformClass, even though it remains unchanged. This adds unnecessary code and can make the transformation's intent harder to grasp at a glance.

Compliant Solution:

public static void transformClassFile(Path path) throws IOException {
    ClassFile classFile = ClassFile.of();
    ClassModel classModel = classFile.parse(path);
    byte[] newBytes = classFile.transformClass(classModel,
      (classBuilder, classElement) -> {
        if (!(classElement instanceof MethodModel methodModel &&
            methodModel.methodName().stringValue().startsWith("debug"))) {
            classBuilder.with(classElement);
        }
      });
}

The compliant solution uses the simpler, two-argument overload of transformClass. By removing the redundant class name parameter, the code becomes more direct and effectively communicates that the transformation modifies the class in place without renaming it.

Rule S7478: `transformClass` should be used to modify existing classes

The Class-File API (JEP 484) provides developers with two primary methods for generating class files: build and transformClass. While build is a general-purpose tool for creating a class from scratch, transformClass is specifically designed for the common task of modifying an existing class.

A frequent pattern in bytecode manipulation is to parse a class, iterate through its elements (like methods or fields), and write a new version with some elements removed or altered. Implementing this pattern with build requires manually iterating over the original class's elements and adding them one by one to a new ClassBuilder. This approach is verbose and full of boilerplate code that obscures the core transformation logic.

This rule encourages using the transformClass method for such tasks. It abstracts away the manual iteration, leading to code that is more declarative, easier to read, and clearly expresses the intent of transforming an existing class model.

Noncompliant Code Example:

public static void transformClassFile(Path path) throws IOException {
  ClassFile classFile = ClassFile.of();
  ClassModel classModel = classFile.parse(path);
  byte[] newBytes = classFile.build( // Noncompliant
    classModel.thisClass().asSymbol(), classBuilder -> {
        // Manual iteration over class elements is boilerplate
        for (ClassElement classElement : classModel) {
          if (!(classElement instanceof MethodModel methodModel &&
              methodModel.methodName().stringValue().startsWith("debug"))) {
            classBuilder.with(classElement);

          }
        }
    });
  Files.write(path, newBytes);
}

This code manually rebuilds the class using build, requiring an explicit loop to copy over the elements that are being kept. This boilerplate distracts from the actual goal: filtering out debug methods.

Compliant Solution:

public static void transformClassFile(Path path) throws IOException {
  ClassFile classFile = ClassFile.of();
  ClassModel classModel = classFile.parse(path);
  byte[] newBytes = classFile.transformClass(
    classModel, (classBuilder, classElement) -> {
      // The transform is applied to each element, no manual loop needed
      if (!(classElement instanceof MethodModel methodModel &&
            methodModel.methodName().stringValue().startsWith("debug"))) {
          classBuilder.with(classElement);
        }
      });
  Files.write(path, newBytes);
}

The compliant solution uses transformClass, which handles the iteration implicitly. The provided lambda is applied to each ClassElement, allowing the developer to focus solely on the transformation logic. The resulting code is more concise, readable, and less error-prone.

Java 24: Stream Gatherers

Java 24 also introduces Stream Gatherers (JEP 461), a new feature designed to enhance the Stream API by allowing for custom intermediate stream operations. Unlike existing map\, filter\, or reduce\ operations, Gatherers enable more complex, stateful, and flexible transformations of stream elements. This allows developers to implement operations like grouping, windowing, or de-duplication directly within the stream pipeline, leading to more expressive, efficient, and readable code for advanced data processing scenarios.

SonarQube continues its commitment to code quality by introducing new rules specifically for Java 24's Stream Gatherers. These rules — including S7481 , S7482 and S7629 — are designed to guide developers in effectively leveraging this powerful new Stream API feature. They ensure that your custom intermediate stream operations are implemented efficiently and clearly, promoting best practices and helping to avoid common pitfalls associated with stateful and stateless gatherers, leading to more robust and readable stream pipelines.

Rule S7481: Sequential gatherers should use `Gatherer.ofSequential`

The introduction of Stream Gatherers (JEP 461) in Java provides a powerful way to create custom intermediate operations in stream pipelines. When creating a gatherer, the API offers two main factories: Gatherer.of(...) for gatherers that can be used in both sequential and parallel streams, and Gatherer.ofSequential(...) for those designed exclusively for sequential processing.

A common pattern for a sequential-only gatherer is to provide a combiner function—the third argument in Gatherer.of(...)—that simply throws an exception, as it's never expected to be called. This, however, is a signal that the gatherer is not truly parallel-capable.

This rule helps improve code clarity by guiding you to use the more specific Gatherer.ofSequential(...) factory in these cases. Doing so makes the intended processing model explicit, removes the need for a dummy or throwing combiner, and makes the code cleaner and easier to understand.

Noncompliant Code Example:

public static List<Integer> diffWithFirstPositive(List<Integer> list) {
  Gatherer<Integer, AtomicInteger, Integer> gatherer = Gatherer.of(
    () -> new AtomicInteger(-1),
    (state, number, downstream) -> {
      if (state.get() < 0) {
        state.set(number);
        return true;
      }
      return downstream.push(number - state.get());
    },
    (_, _) -> { // The combiner is never meant to be called
      throw new IllegalStateException();
    },
    Gatherer.defaultFinisher());
  return list.stream().gather(gatherer).toList();
}

In this code, the presence of a combiner that unconditionally throws an IllegalStateException is a clear indicator that the gatherer cannot function in a parallel stream.

Compliant Solution:

public static List<Integer> diffWithFirstPositive(List<Integer> list) {
  Gatherer<Integer, AtomicInteger, Integer> gatherer = Gatherer.ofSequential(
    () -> new AtomicInteger(-1),
    (state, number, downstream) -> {
      if (state.get() < 0) {
        state.set(number);
        return true;
      }
      return downstream.push(number - state.get());
    },
    Gatherer.defaultFinisher());
  return list.stream().gather(gatherer).toList();
}

By switching to Gatherer.ofSequential, the code becomes more obvious about its intent. It clearly communicates that the operation is sequential-only and eliminates the unnecessary and misleading throwing combiner, resulting in a cleaner implementation.

Rule S7482: Stateless gatherers should be created without a null initializer

Stream Gatherers can be either stateful—maintaining a state across elements—or stateless, processing each element independently. For stateless gatherers, there is no need to initialize a state object. The java.util.stream.Gatherer API reflects this distinction by providing overloaded factory methods, including versions that do not take an initializer function.

When creating a stateless gatherer, it is a common mistake to use a factory method that requires an initializer and simply provide a dummy one, such as () -> null. This practice, while functional, makes the code less clear and fails to communicate the gatherer's stateless nature effectively.

This rule encourages the use of the correct factory method for stateless gatherers. By choosing the factory that omits the initializer, you make the stateless design explicit and your code more concise and readable.

Noncompliant Code Example:

private static Gatherer inRange(int start, int end) {
    return Gatherer.<Integer, Void, Integer>ofSequential(
      () -> null, // Noncompliant: unnecessary initializer for a stateless gatherer
      (_, element, downstream) -> {
        if (element >= start && element <= end)
          return downstream.push(element - start);
        return !downstream.isRejecting();
      },
      (_, downstream) -> downstream.push(-1)
    );
}

Here, the () -> null initializer serves no purpose other than to satisfy the signature of the factory method. This adds unnecessary boilerplate and obscures the fact that the operation does not depend on a state.

Compliant Solution:

private static Gatherer inRange(int start, int end) {
    return Gatherer.<Integer, Integer>ofSequential(
      (_, element, downstream) -> {
        if (element >= start && element <= end)
          return downstream.push(element - start);
        return !downstream.isRejecting();
      },
      (_, downstream) -> downstream.push(-1)
    );
}

The compliant solution uses the appropriate Gatherer.ofSequential overload that does not require an initializer. This removes the redundant code and clearly signals to anyone reading it that the gatherer is stateless by design.

Rule S7629: When a defaultFinisher is passed to a Gatherer factory, use the overload that does not take a finisher

The java.util.stream.Gatherer API, used for creating custom stream operations, provides overloaded factory methods like of(...) and ofSequential(...). Some of these overloads accept a finisher function to perform a final action after all elements have been processed.

However, the API also provides a Gatherer.defaultFinisher(), which does nothing. Passing this default finisher to a factory method is redundant and adds unnecessary boilerplate to the code. Using the simpler overload of the factory method that does not take a finisher at all achieves the same result while more clearly communicating that no special finishing action is needed.

This rule helps you write more concise code by flagging the unnecessary use of Gatherer.defaultFinisher().

Noncompliant Code Example :

Gatherer<Integer, AtomicInteger, Integer> gatherer = Gatherer.ofSequential(
  () -> new AtomicInteger(-1),
  (state, number, downstream) -> {
    if (state.get() < 0) {
      state.set(number);
      return true;
    }
    return downstream.push(number - state.get());
  },
  Gatherer.defaultFinisher()); // Noncompliant: this finisher is useless

In this code, Gatherer.defaultFinisher() is explicitly passed, making the code more verbose than necessary for no additional benefit.

Compliant Solution :

Gatherer<Integer, AtomicInteger, Integer> gatherer = Gatherer.ofSequential(
  () -> new AtomicInteger(-1),
  (state, number, downstream) -> {
    if (state.get() < 0) {
      state.set(number);
      return true;
    }
    return downstream.push(number - state.get());
  }); // Compliant

The compliant solution removes the default finisher and calls the simpler overload of Gatherer.ofSequential. The functionality is identical, but the code intent—that no special finisher is required—is perfectly clear.

Java and SonarQube

By embracing the new features in Java 22, 23, and 24—such as unnamed variables and patterns, Markdown in Javadoc, the Class-File API, and Stream Gatherers—developers can write more efficient, and more maintainable code resulting in a higher-quality code. However, staying abreast of these evolving language enhancements and consistently applying best practices can be challenging.

This is where tools like SonarQube, become invaluable. They provide automated checks that help ensure your code not only leverages these modern features correctly but also adheres to high-quality standards, ultimately improving code clarity and overall project quality.

Diving Deep into SonarQube's AI CodeFix: A Hands-On Experiment with Eclipse JKube

Jonathan Vila — Wed, 04 Jun 2025 20:27:17 +0000

SonarQube has long been a staple in a Java developer's toolkit for maintaining code quality. With the introduction of its AI CodeFix feature, SonarQube promises to take automated code remediation to the next level. This article explores a practical experiment conducted using SonarQube's AI CodeFix on the open-source Java project, Eclipse JKube. We'll delve into the setup, the process, the successes, and the challenges encountered, offering insights for Java developers looking to leverage this cutting-edge technology.

AI impact in the development lifecycle

AI code generation offers accelerated development by automating repetitive tasks and suggesting solutions with access to a long list of sources. This, combined with the deterministic analysis executed by SonarQube, produces a powerful solution that will boost the development experience.

You have to keep in mind, especially when using AI generated code, that critical oversight, thorough review, and continued skill development are essential. Treating AI as a helpful tool rather than a complete replacement ensures that developers leverage its power effectively while maintaining control and understanding of their codebase.

AI has a huge potential in enhancing developer productivity and improving code quality. The experiment with JKube highlighted that while it's not a silver bullet, it's a powerful assistant for specific types of code cleanup.

What is SonarQube offering here to help?

SonarQube, the code quality guardian tool you’ve been using to ensure your project quality and security, has an advanced feature called AI CodeFix. This feature leverages artificial intelligence to automatically suggest fixes for detected code issues, moving beyond simple static analysis and offering practical remediation suggestions.

AI CodeFix aims to streamline the process of code maintenance and quality improvement by:

Identifying Code Issues: SonarQube performs in-depth code analysis to pinpoint various issues, ranging from stylistic inconsistencies to potential bugs and vulnerabilities.
Generating AI-Driven Suggestions: When a code issue is identified, AI CodeFix attempts to generate a specific code change that would resolve the problem. These suggestions are based on patterns learned from vast amounts of code and best practices.
Providing Contextual Solutions: The AI-generated fixes are designed to be contextually relevant, taking into account the surrounding code and the nature of the issue.
Facilitating Quicker Resolutions: By providing direct fix suggestions, AI CodeFix can significantly reduce the time developers spend manually debugging and correcting issues, allowing them to focus more on feature development.
Enhancing Learning: Developers can learn from the AI suggestions, gaining insights into better coding practices and common pitfalls to avoid.

In essence, SonarQube AI CodeFix acts as an intelligent assistant, proactively identifying and suggesting remedies for code quality issues, thus contributing to cleaner, more reliable code.

These modifications play a significant role in maintaining code integrity. Let's explore the impact of these specific fixes on the overall project health and efficiency.

From the SonarQube issue description page, for certain rules, you see the “Generate AI Fix” button.

And clicking on it, SonarQube will produce the fix for that particular issue.

Clicking on “View fix in IDE” will open your current local IDE on the file with the changes.

AI CodeFix delivers valuable results for a selected subset of rules, confirmed through testing. These targeted rules undergo verification to ensure performance enhancements. Focusing on this checked subgroup optimizes the utility of the AI tool.

Eclipse JKube: An Overview

Eclipse JKube is an open source collection of plugins and tools for Kubernetes and OpenShift that simplify the process of building and deploying Java applications to containerized environments. It aims to provide a streamlined, developer-friendly experience, reducing the complexity of working with Kubernetes and OpenShift directly.

It simplifies and streamlines the process of building container images (using Docker, JIB, or S2I strategies) and deploying Java applications to Kubernetes and OpenShift. Users appreciate its "zero-configuration" capability for quick starts, while also offering flexible XML and external template configurations for more complex needs. JKube effectively bridges the gap between Java applications and cloud-native environments.

The Eclipse JKube project itself maintains a rich repository of quickstart projects. These demonstrate how to use JKube with various Java frameworks and technologies, including: Spring Boot, Quarkus, Micronaut, Vert.x, Open Liberty, Apache Camel, Apache Karaf among others, and companies like Red Hat are heavily using it and contributing to it.

Key Features and Objectives of JKube

Simplified Kubernetes Development: JKube simplifies the process of creating Kubernetes manifests, building container images, and deploying applications. Developers can focus more on writing code and less on configuration details.
Maven and Gradle Integration: It integrates seamlessly with popular build tools like Maven and Gradle, allowing developers to manage their Kubernetes deployments as part of their existing build processes.
OpenShift Support: In addition to Kubernetes, JKube also supports OpenShift, Red Hat's enterprise Kubernetes platform, making it versatile for different environments.
Zero Configuration Defaults: JKube provides sensible default configurations that work for many common Java application scenarios, minimizing the need for manual configuration.
Hot Reloading and Debugging: It supports features like hot reloading, which allows developers to see changes in their application without restarting the entire container, and remote debugging for troubleshooting.
Resource Generation: JKube automatically generates Kubernetes resource descriptors from project metadata, reducing the amount of YAML configuration required.
Extensibility: The plugin is designed to be extensible, allowing developers to customize or add new features as needed.

How JKube Works

JKube uses a combination of build tool plugins and libraries to achieve its goals. When a project is built with JKube, it:

Analyzes Project Metadata: JKube inspects the project's POM file (for Maven) or build.gradle (for Gradle) to gather information about the application, such as dependencies, ports, and environment variables.
Generates Kubernetes Manifests: Based on the project metadata, JKube automatically generates the necessary Kubernetes resource descriptors (YAML files) for deploying the application.
Builds Container Images: It handles the process of building container images (Docker or Podman) that package the application and its dependencies.
Deploys to Kubernetes/OpenShift: JKube can directly deploy the built image to a Kubernetes or OpenShift cluster, simplifying the deployment workflow.

Benefits of Using JKube

Increased Developer Productivity: By automating much of the Kubernetes and OpenShift interaction, JKube allows developers to spend more time coding and less time managing infrastructure.
Reduced Configuration Overhead: JKube's zero-configuration defaults and automatic resource generation reduce the complexity of configuring deployments.
Consistent Deployments: JKube ensures consistent deployments across different environments by using the same build process and metadata.
Faster Iteration: Features like hot reloading and remote debugging speed up the development cycle and make it easier to troubleshoot issues.
Simplified CI/CD Integration: JKube can be easily integrated into Continuous Integration/Continuous Deployment (CI/CD) pipelines, automating the deployment process further.

AI CodeFix in Action: A Module-by-Module Breakdown

The experiment focused on targeting specific modules within JKube: openshift-maven-plugin, kubernetes-maven-plugin, and gradle-plugin. The general workflow for each issue involved navigating to it in the SonarQube server, clicking the "CodeFix" button to see the suggestion, and then attempting to view it in the IDE, accept the changes, commit and create the Pull Request.

These are some of the issues detected during the process with their explanation and the specific changes implemented:

Openshift-maven-plugin

Issue Remove the declaration of thrown exception 'java.io.IOException', as it cannot be thrown from method's body (S1130)
- Superfluous exceptions within throws clauses have negative effects on the readability and maintainability of the code. An exception in a throws clause is superfluous if it is:
- listed multiple times
- a subclass of another listed exception
- not actually thrown by any execution path of the method

Kubernetes-maven-plugin

Issue Rename "remoteDevelopmentService" which hides the field declared at line 39.(S1117)
- Shadowing occurs when a local variable has the same name as a variable or a field in an outer scope.
- This can lead to three main problems:
- Confusion: The same name can refer to different variables in different parts of the scope, making the code hard to read and understand.
- Unintended Behavior: You might accidentally use the wrong variable, leading to hard-to-detect bugs.
- Maintenance Issues: If the inner variable is removed or renamed, the code’s behavior might change unexpectedly because the outer variable is now being used.

Issue Use a primitive boolean expression here (S5411)
- When boxed type java.lang.Boolean is used as an expression to determine the control flow (as described in Java Language Specification §4.2.5 The boolean Type and boolean Values) it will throw a NullPointerException if the value is null (as defined in Java Language Specification §5.1.8 Unboxing Conversion).
- It is safer to avoid such conversion altogether and handle the null value explicitly.

Gradle-plugin

This module saw more consistent success:

Issue Define a constant instead of duplicating this literal "jkube" 5 times (S1192)
- Duplicated string literals (more than 5 times) make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences.

Issue Replace this lambda with method reference 'task::mustRunAfter' (S1612)
- Method or constructor references are more readable than lambda expressions in many situations, and may therefore be preferred.
- However, method references are sometimes less concise than lambdas. In such cases, it might be preferable to keep the lambda expression for better readability. Therefore, this rule only raises issues on lambda expressions where the replacement method reference is shorter

Key Takeaways for Java Developers

SonarQube's AI CodeFix is a promising feature that can undoubtedly speed up the process of addressing certain types of code quality issues.

For now, Java developers can benefit from using AI as a helpful co-pilot, always keeping a discerning eye on the suggestions before committing them to the codebase.

Based on this experiment:

Trust but Verify: While AI can provide valuable suggestions, developers must meticulously review each proposed change. Automatic application without review can lead to compilation errors or introduce unintended behavior.
Best for Boilerplate: The feature seems most reliable for common, boilerplate-style fixes like removing unused code, simple refactorings, and enforcing consistent style.
Complex Logic is Still Human Domain: For more complex issues, especially those described in TODO comments requiring new logic or significant code modification, the developer is the important part. AI definitely help the developer to focus on important tasks.
Iterative Improvement: AI technology is rapidly evolving. The issues and limitations observed in this experiment might be addressed in future versions of SonarQube.
Tooling Limitations: The lack of bulk fixing and refined filtering options for AI-ready fixes can slow down the process if a project has many issues. The API approach for automation also hit a snag.

➡️ AI gives you ✅ 𝐓𝐈𝐌𝐄 not ❌𝐂𝐎𝐍𝐅𝐈𝐃𝐄𝐍𝐂𝐄 : Developer productivity toolkit

Jonathan Vila — Fri, 23 May 2025 12:52:04 +0000

Let's be real – keeping up with the pace of software development today is intense. New frameworks pop up and the push for faster, better, and more secure code never stops.

This article is all about cutting through the buzz and looking at how AI-powered tools can actually help you, the Java developer, day-to-day. We'll dive into specific ways AI can help you through the whole SDLC:

Understanding Complex Tasks
Accelerating Code Creation
Streamlining Cloud Deployment
Creating Effective Tests
Increasing Code Quality and Security
Improving Code Review

Using AI to Understand Complex Tasks

Okay, first up: wrapping your head around the job at hand. You know those moments where you need to implement a feature based on requirements that feel a bit… fuzzy. Traditionally, this means lots of reading, maybe drawing diagrams, and asking clarifying questions.

Here's where AI can lend a hand. Think of tools like GitHub Copilot, Windsurf and Cursor ,among others, as smart summarizers and brainstorming partners.

Digest Docs: Feed the AI that long requirements doc and ask it to summarize the key points related to a specific feature.
Clarify Ambiguity: Try phrasing a requirement as a question to the AI. "Explain the user session timeout logic described here "
Break It Down: Feeling overwhelmed by a big task? Describe the goal to the AI and ask it to suggest potential steps or components.
Connect it to your code base: Feed your code base to the AI assistant , link the requirements doc and ask the AI where you should put the new code.

Getting Specific with Github issues and Your Code:

Now, what about pointing the AI at a specific issue ticket and your actual codebase to figure out where to start coding? This is getting more powerful:

IDE Integrations are Key: Tools like GitHub Copilot operate right within your IDE. You can copy the core description from your Jira ticket into the chat panel and ask something like: "Based on this ticket #1, what services might I need to modify?"
Codebase-Aware AI : Some newer tools like Cursor can actually index your entire codebase. This allows for more powerful queries. You might be able to ask: "Where in our codebase is the logic related to 'JIRA-456' located?"
AI Tool integration: MCP servers (more details below) connect your AI assistant directly to servers in order to add capabilities to the Agent. In this case it’s the Github API that will give read or write information regarding the current repository issues.

As an example, you can use Github Code Spaces with Copilot Agent Mode , and it will give us an explanation of the ticket and the changes to do.

Important Caveats:

Security First: Be very careful about pasting internal code or sensitive information into public AI tools.
It's a Guide, Not a Guru: Treat the AI's output as educated guesses. It's a starting point to accelerate your own investigation. You still need your developer brain to validate its reasoning.

Using AI this way is about accelerating the initial investigation phase. It helps you form a hypothesis about where to look and what might be involved so you can jump into the interesting design and coding parts sooner.

Accelerating Code Creation

Okay, let's talk about actually producing Java code. This is where tools like GitHub Copilot in VS Code really shine. Think of them as having a pair programmer who types really fast and knows a ton of standard library calls, common patterns and the company's codebase.

Killing Boilerplate: We all know Java can be a bit verbose sometimes. Need to write constructors, accessors, equals(), hashCode() for a POJO? These tools can generate them based on the fields you've declared.
Generating Snippets and Methods: Write a clear method signature and the AI will generate a surprisingly decent implementation. You can use different methods to generate code:.
- Inline chats Ask the assistant to generate “Java method to fetch data from API endpoint XYZ and parse the JSON response” and wait a bit. The AI might suggest the entire method body using HttpClient or RestTemplate.

Ghost text: Start typing a typical Spring Boot controller method like @GetMapping("/products/{id}") public ResponseEntity<Product> getProductById ... The AI will likely suggest the code to call a service and return the response.

How Context Improves Suggestions:

These tools use the context of your project to tailor suggestions. But how do they get this context?

Primarily Your Open Files: The AI heavily analyzes the code in the file(s) you currently have open in your editor.
Chat & Explicit Prompts: Mentioning specific class/method names from your project or pasting relevant snippets guides the AI. For example: "Using our CustomerService class, generate the boilerplate code for a new method findCustomerByEmail(String email) that calls the customerRepository."
Codebase Awareness: Specialized tools using Agents can be set up to index your entire codebase. This allows for much deeper context, potentially leading to suggestions that understand your project's specific patterns even if the relevant files aren't currently open.

List of context elements to add in a chat

Why Context Matters: This context is crucial. It means the AI is more likely to suggest code that:

Calls your existing helper functions or service methods.
Follows the coding style and patterns already present in the file.
Uses the correct versions of libraries already defined in your project dependencies.

The result? Code suggestions feel less generic and much more like they actually belong in your specific project.

Using the right context also helps on two important points :

Learning New Libraries: Trying out a new Java library or framework feature? You can often just write a comment describing what you want to achieve ("// Use Apache Commons CSV to write records to a file") and let the AI generate a starting example, often using the context of your existing code style.
Quick Mockups: Need a quick data transformation or a utility function? Describe it in a comment or start typing, and let the AI fill it in, leveraging context for better results.

For Experienced Devs: Look, this isn't about the AI writing your core, complex business logic. You're still the architect and the problem solver. AI can handle some of the work by leveraging your codebase context, it frees you up to focus on the harder, more valuable parts of the system.

It takes a little getting used to, and you absolutely must review the generated code (even context-aware AI isn't perfect!).

Integrating Specialized Agents and Reasoning in Agentic IDEs: Agentic IDEs can significantly enhance code generation by employing various specialized agents, each tailored for specific tasks like API interaction, database querying, or UI component creation. Moreover, these IDEs can provide detailed reasoning behind the generated code, outlining the steps taken improving developer understanding and trust in the AI's output.

In tools like VS Code with Github Copilot or Cursor, we can even tailor the behaviour of the agents when they generate code.

Here we can specify to use the latest Java 24 features, or a specific version of Quarkus, or even which front end frameworks to use, among other particularities of your code.

Advanced tip : ask the assistant to create an instructions file based on your current code base structure as the template for all future projects.

MCP servers to the rescue: MCP servers greatly enhance code generation and understanding by facilitating connections to specialized tools, expanding knowledge beyond typical Large Language Model (LLM) training data. Several IDEs like Windsurf, Cursor or VS Code with Copilot support this technology, enabling developers to leverage MCP-driven AI within their coding environment.

For instance, using an MCP server connected to a database tool, the assistant can generate CRUD (Create, Read, Update, Delete) operations tailored to each table in a database, incorporating specific data types, relationships, and constraints.

There are several places where we can get MCP servers for specific tasks and with a very easy installation process : https://mcpservers.org/ , https://mcpmarket.com/, https://mcp.so/ , etc.

This is an example of installation of a Docker MCP server implementing the GitHub tools, that will allow our assistant to connect to our GitHub repository and get issues, branches, PRs, etc.

These MCP servers expose tools to be used by the agent. In this case the Github MCP Server share 36 tools :

Streamlining Cloud Deployment

Okay, so your Java code is looking good. Now, how about actually shipping it? Getting applications deployed to the cloud involves writing a lot of configuration – Dockerfiles to containerize your app, Kubernetes YAML for orchestration, and CI/CD pipeline definitions (GitHub Actions, GitLab CI, etc.).

This is another area where AI assistants can save you significant time and effort, acting as configuration generators.

Generating Dockerfiles: Need to containerize your Spring Boot or Quarkus app? Instead of starting from scratch, ask your AI assistant: "Generate a multi-stage Dockerfile for a Java 21 Maven project that builds the JAR and runs it using an OpenJDK JRE slim image."
Scaffolding Kubernetes Manifests: Get a head start by asking: "Create a Kubernetes Deployment YAML for an app named 'order-service', using image 'my-repo/order-service:v1', with 3 replicas and exposing container port 8080."
Infrastructure as Code (IaC) Templates: Need a basic Terraform configuration? Describe what you need: "Write a simple Terraform configuration (HCL) to create an AWS S3 bucket named 'my-app-data-bucket' with versioning enabled."
CI/CD Pipeline Starters: Setting up a build and test pipeline? Ask: "Generate a basic GitHub Actions workflow file that checks out code, sets up Java 21, builds with Maven, and runs unit tests."
Debugging Config Errors: Pasting a cryptic error message from kubectl into an AI chat and asking "What does this error mean and how can I fix it?" can point you in the right direction faster than searching online.

Agentic MCP AI is your friend: Getting the logs or the configuration for running apps in your cluster can be crucial to produce more aligned code. For instance, getting the CRDs in your cluster can help you create a better Kubernetes operator that reacts to changes on them.

You can rely on the multiple MCP servers with your Agentic AI assistant to consider that information when you are chatting with it. Kubernetes MCP server is a clear example of this and it gives you 15 tools to interact with your K8s cluster.

VS Code with Github Copilot using Kubernetes MCP to interact with a local cluster

Java Context Matters: When generating configs for Java apps, you can get specific. Ask for Dockerfiles that set appropriate JAVA_OPTS environment variables for JVM memory limits (-Xms, -Xmx).

⚠️ Hold Up! Review Carefully! ⚠️

Just like with generated code, AI-generated configuration files are starting points, NOT final products. You absolutely need to review them carefully:

Security is Paramount: This is critical. AI might generate insecure configurations – hardcoded secrets, overly permissive IAM roles or network policies (like 0.0.0.0/0). Security configurations MUST be reviewed by someone knowledgeable. Don't assume the AI got it right.
Check for Best Practices: Does the generated config follow current best practices for the specific cloud provider or tool? AI knowledge might be outdated or too generic.
Understand, Don't Just Copy: Make sure you understand what the configuration actually does before applying it. You're still responsible for the infrastructure and deployment.
Test Thoroughly: Deploy to a non-production environment first and test rigorously.

Reinforce with IaC Static Analysis:

Beyond manual review, remember that specialized static analysis tools can also help validate your Infrastructure as Code (IaC) files. Tools like SonarQube (which supports Terraform, Kubernetes YAML, Dockerfiles, etc.), are designed specifically to scan these configuration files. They check for:

Common security misconfigurations
Adherence to cloud provider best practices
Potential syntax errors or logical issues
Secrets misusage

Integrating these IaC scanners into your CI/CD pipeline adds an essential automated check. It complements manual reviews and helps catch issues in both human-written and AI-generated configurations before they potentially impact your deployed environment.

Creating Effective Tests

Ah, testing. We all know it's crucial for catching regressions, ensuring correctness, and enabling confident refactoring. But it can also be time-consuming. Good news! AI can lend a hand here, helping you generate tests faster.

Generating Unit Test Scaffolding: You can ask to generate tests to your AI assistant on a Java class or method. The AI will attempt to create a test class (e.g., using JUnit 5) with basic test methods covering the public methods of your source class.
Suggesting Test Cases: You can use AI chat features to brainstorm. Paste your method's code and ask: "What are some important edge cases I should test for this Java method?"
Creating Mock Objects: Setting up mocks can be tedious. AI assistants can often generate the necessary @Mock annotations, injection points (@InjectMocks), and when(...).thenReturn(...) statements based on how your class interacts with its dependencies. For example: "Generate a JUnit test for this OrderService method, mocking the ProductRepository"

Copilot chat asking it to generate the test methods

Tests generated by Copilot for this method

⚠️ HUGE WARNING: Review Generated Tests Like Crazy! ⚠️

This is possibly even more critical than reviewing generated application code: AI-generated tests MUST be thoroughly reviewed and often significantly refined.

Common AI test generations :

AI Doesn't Understand Intent: AI tests the code as it's written. It doesn't know the business requirements or the intended behavior. If your code has a bug, the AI might happily generate a test that confirms the buggy behavior!. In this case it doesn’t make any sense to have a total tax of -1000 , and AI has tested that the test is really verifying what the code is doing, including the bug.

Trivial and Meaningless Tests: AI often generates tests for simple getters/setters or very basic logic that might not provide much value. It might miss the truly complex or critical paths.
Incorrect Assertions: The assertions generated might be wrong, incomplete, or nonsensical. Don't assume they are correct.
Poor Quality: Generated tests might not follow best practices for naming, structure, or readability, making them hard to maintain.
Over-reliance on Mocking: AI might excessively mock things, leading to brittle tests that don't actually verify useful interactions.

How to Use AI for Testing Effectively:

Use it as a Starting Point: Let AI generate the boilerplate structure, basic happy-path tests, and mock setups.
Focus Your Effort: Use the time saved to focus on writing tests for the complex logic, critical business rules and tricky edge cases – the areas where human understanding is essential.
Critically Review & Refine: Read every generated test. Does it make sense? Is it testing something important? Is the assertion correct? Is it readable?
Don't Chase Coverage Blindly: AI can quickly increase test coverage numbers, but coverage isn't the same as quality. A few meaningful tests are better than hundreds of trivial ones.
Provide the right context: including functional testing information, or feature requirements will help AI assistants to tailor the test to what it’s supposed to be tested and not what it is written in the code. In this case we are asking to create the tests but considering the requirements specified in a github issue.

Don't Forget Static Analysis for Test Code:

One more point on test quality: don't forget that static analysis tools can also help here! Tools like SonarQube, Checkstyle, and PMD often include specific rule sets designed to analyze your test code, not just your production code. They can check for:

Common testing anti-patterns.
Adherence to JUnit/testing framework best practices .
Potential bugs in tests .
Unused test code or helper methods.
Consistency in naming conventions for test classes and methods.

Running these analyzers on your test suites is another good practice, especially when incorporating AI-generated tests.

Improving Code Reviews

Alright, let's talk about pull requests (PRs) and code reviews. They're super important for team health and code quality, but they can also be time-consuming and sometimes frustrating. Understand a massive PR, catching subtle issues and providing constructive feedback. And if you're the author, waiting for reviews and addressing comments takes time too.

How AI Helps Reviewers:

Quick Summaries: Tools like GitHub Copilot can automatically generate summaries of the changes in a PR. This helps reviewers quickly grasp the purpose and scope of the changes before diving into the code details.

They can even interact with the PR using extensions in order to provide functionalities that are out of the scope of the LLM like creating Mermaid diagrams for the classes.

Automated First Pass (via CI/CD): Remember those static analysis (SAST) and IaC scanning tools we discussed? Integrating them into your CI/CD pipeline to run automatically on PRs is a huge win.

How AI Helps Authors:

Pre-Submission Polish: Authors can use AI coding assistants (Copilot Chat, IntelliJ AI Assistant) in their IDE to refine, and improve their code before even creating the PR. Asking "Can this code be simplified?" can catch issues early.
Implementing Feedback: If a reviewer asks for a specific change, an author could potentially ask their AI assistant for suggestions on how to implement that feedback efficiently and correctly.
Generating Related Artifacts: AI can help generate or update comments (like Javadoc for changed methods) or even draft basic documentation snippets related to the code changes, making the PR more complete.

⚠️ AI Assists, It Doesn't Replace Human Review! ⚠️

This is crucial: AI is a code review assistant, not a replacement for human reviewers.

Context is King: AI often lacks the deep understanding of the project's history, overall architecture, business requirements, and long-term goals that experienced human reviewers bring. Add the proper context for each prompt. You can even guide AI answers with the Personal instructions directly in the Github Pull Request page.

Design & Logic Still Need Humans: AI is generally poor at evaluating the appropriateness of a design choice or the correctness of complex business logic. That requires human critical thinking.
Knowledge Sharing: Code reviews are vital for team learning and knowledge sharing – something AI assistance doesn't replace.
Evaluate AI Output: Reviewers need to critically assess any summaries or issues flagged by AI.

Think of AI in code review as handling the first-pass checks, summarizing changes, and assisting with implementation details. This frees up valuable human reviewer time to focus on the deeper aspects of code quality, design, and correctness.

Increasing Code Quality and Security

Writing high-quality, secure Java code is crucial, going beyond just making things work. It's vital to understand AI limitations, especially regarding reliability. Let's explore how AI can help refine code and how traditional tools remain essential for verification.

Using AI for Code Refinement and Understanding:

Where AI can be a valuable assistant is in helping you, the developer, understand and improve code:

Untangling Complexity: Use AI chat assistants to explain complex Java code sections.
Refactoring Collaboration: Ask the AI for suggestions on refactoring specific methods for better readability, simplification, or to apply certain patterns ("Refactor this using Java Streams" or "How can I simplify this nested logic?"). Treat these suggestions as ideas to be critically evaluated and adapted by you.
Learning Best Practices: Use AI to ask questions about secure coding practices ("What are common pitfalls with Java serialization?") .

⚠️ THE GIANT RED FLAG: AI IS NOT RELIABLE FOR ISSUE DETECTION ⚠️

https://dl.acm.org/doi/pdf/10.1145/3558489.3559072

Now, regarding finding bugs and security vulnerabilities: relying on AI for direct issue detection is highly risky due to its fundamental lack of correctness and predictability guarantees.

Why the Risk? AI Makes Mistakes: AI models can hallucinate findings, generate numerous false positives, miss critical vulnerabilities, or provide incomplete/incorrect security advice. They operate on patterns, not deterministic analysis. Therefore, AI is NOT a substitute for proper analysis tools.

The Solution: Deterministic Static Analysis (SAST)

Because AI cannot be trusted for reliable issue detection, you must use dedicated Static Application Security Testing (SAST) tools. These are the right tools for the job:

Tools: SonarQube, Checkstyle, PMD, etc.
Why They Work: SAST tools operate by applying defined, verifiable rulesets and analysis techniques in a deterministic way.
Best practices:
- Use tooling as soon as possible in your SDLC. Incorporate these SAST tools in the IDE to analyze the quality of your code at the same time you are introducing new changes.

SonarQube IDE view with an issue and its explanation

Connect your CI/CD pipeline with a Quality Gate tool in order to ensure no bad code is going to be merged to your main branch.

Use Quality Gate messages in your Pull Requests through PR decoration.

Essential Supporting Pillars: Testing and Reviews using Human skills

Alongside reliable SAST, robust engineering practices remain critical:

Rigorous Testing (TDD!): Test-Driven Development provides concrete proof that your code meets requirements and handles various scenarios correctly.
Human Code Reviews: Critical examination by experienced peers is essential to catch logical flaws, architectural issues, and subtle security concerns that automated tools (whether AI-based or traditional) might miss.
Pair Programming: This practice inherently includes collaborative review and discussion, promoting higher quality code, especially when integrating any new tool or technique like AI assistance.

In Summary: Leverage AI assistants carefully for tasks where they excel – helping you understand, refactor, and learn. But for the critical task of identifying bugs and security vulnerabilities, trust deterministic SAST tools. Combine this with rigorous testing and thorough code reviews to build truly high-quality, secure Java applications.

Conclusion

So, what's the bottom line here? Is AI going to take over Java development? Not anytime soon. But is it becoming a genuinely useful, practical tool that can make our lives as developers easier and more productive? Absolutely.

The real takeaway is to think of these AI tools not as replacements, but as powerful assistants or co-pilots. By offloading some of that work to AI, you get more time and energy to focus on the truly challenging and rewarding parts of software development.

But (and it's a big but!), remember those warnings we sprinkled throughout. AI isn't magic, and it's certainly not infallible. Critical thinking, thorough review, rigorous testing, deterministic static analysis, and collaborative code reviews are more important than ever.

And remember : ➡️ 𝑨𝑰 gives you ✅ 𝐓𝐈𝐌𝐄 not ❌𝐂𝐎𝐍𝐅𝐈𝐃𝐄𝐍𝐂𝐄

Happy coding!

AI Test Generation: A Dev's Guide Without Shooting Yourself in the Foot

Jonathan Vila — Mon, 28 Apr 2025 10:05:21 +0000

So, AI Can Write Tests Now? Cool, But...🤔

AI assisted coding tools are everywhere now, helping with autocomplete, suggesting fixes, and sometimes writing surprisingly large blocks of code. A hot topic 🚀 is using generative AI to generate tests automatically – unit, integration, e2e, etc. The idea's definitely appealing. Who wouldn't want an AI to help crank out tests, bump up those coverage numbers, and maybe save us from some of the testing grind? It sounds like a fast track to better feedback and tackling that mountain of untested code.

But, hang on a sec. Like any tool, especially one this complex, artificial intelligence is not a silver bullet. Just grabbing AI driven tests and calling it a day is risky. You might think your code's solid because the test count is high, but the tests themselves might be junk. These AI language models learn from tons of code online and in repos – and let's face it, a lot of that code isn't exactly high quality nor correct code.

This article is for devs 👉 figuring out how to actually use these AI tools without creating a mess and produce high quality software. We'll touch on the good stuff but focus on the traps 🪤: the tests might be flat-out wrong, or they might just "prove" that your buggy code works exactly like the buggy mess it is, instead of checking if it meets user needs. We'll also bring in static analysis with SonarQube, using its big list of Java test rules [https://rules.sonarsource.com/java/tag/tests/] to show concrete examples of what can go wrong and what to watch for. The point isn't to ditch AI, but to use it intelligently, so you don't trade real quality for fake coverage.

How AI Learns to Code (And Why That's a Problem for Tests)

To understand why AI tests can be uncertain, it helps to know how these code-generating AIs learn. Most are Large Language Models (LLMs) trained on absolutely massive datasets. These datasets contain billions of lines of code from GitHub, Stack Overflow, open-source projects, maybe your own company's code. The AI digests all this and learns patterns: common code structures, how people usually use certain APIs, popular libraries, coding styles. It gets really good at predicting the next bit of code in a sequence, leading it to write stuff that often looks right.

But that's the catch. The training data is just… code. All kinds of code. Including:

Plain old bugs.
Nasty security holes.
Weird anti-patterns.
Outdated code using old libraries, patterns or approaches.
Code that ignores style guides.
Code with zero useful comments.

The AI doesn't understand good code from bad code. It just mimics the patterns it saw. If buggy code patterns were common in its training data, it'll happily reproduce them. It's the classic "garbage in, garbage out" deal.

So when you ask this AI to write tests, problems pop up:

The Tests Have Bugs: The generated test code itself might be flawed, misuse resources, have race conditions – just like buggy tests humans write.
The Tests Verify Bugs: This is the really sneaky one. The AI looks at your current code, sees how it works (even the buggy parts), and writes a test to confirm that behavior. It doesn't know what the code should do from requirements; it just tests what the code does.

Think of learning English only by reading internet comments. You'd get good at slang and common mistakes, but you wouldn't be able to write clean technical docs. An AI testing tool trained on a huge, messy pile of code is similar – good at mimicry, not guaranteed to be correct or follow best practices in software development.

AI powered tests can be inaccurate and may only validate existing code, not the intended behavior. Let’s see some of the main problems you can encounter by generating the tests with AI.

Problem #1: AI Tests Might Just Be Wrong

Yeah, AI can generate code that uses @test and compiles. It will save a lot of manual effort on time consuming test case generation. But is it correct? Often, it might not be. When you're reviewing AI-generated tests, watch out for:

Looks Right, Works Wrong: AI usually nails the syntax. But code that compiles doesn't mean the test logic is sound or it tests anything useful.

Incomplete Tests: Super common. The AI sets things up, calls the method, and... forgets the important part.

No Asserts: A test without asserts is pointless. AI often forgets to actually check the result.

Weak Asserts: An assertNotNull(result) is better than nothing, but doesn't prove the result is correct. Also assertTrue(true) is useless.

Happy Path Only: AI often tests the simple case. What about nulls, errors, edge conditions? AI might miss these unless you specifically tell it to check them.

Weird or Irrelevant Tests: AI can "hallucinate" and generate tests for things that don't make sense for your app, or test trivial details instead of important behavior.

Sneaky Logic Bugs: These look okay at first glance.

Bad Setup: Mocking things wrong, starting the test in an invalid state.

Bad Asserts: Using the wrong comparison, expecting the wrong result, off-by-one errors.

Flaky Tests: Tests involving threads or async code are hard. AI might generate tests that sometimes pass, sometimes fail due to timing issues.

Missing the Big Picture: Good tests often need domain knowledge. AI usually doesn't have deep context about your specific app unless you give it lots of info. It might test a method fine in isolation but miss its system-wide impact.

Dynamic Stuff & Async: Testing tricky things like UIs, message queues, or async operations? AI often struggles to generate reliable tests for these without a lot of help or manual fixes.

Here’s a quick example:

// AI might generate something like this:
@Test
void testProcessItem() {
    ItemProcessor processor = new ItemProcessor(/* dependencies */);
    Item item = getTestItem();

    // Maybe AI doesn't know mocking is needed here
    // MockItemRepository mockRepo = mock(ItemRepository.class);
    // when(mockRepo.save(any(Item.class))).thenReturn(item);
    // processor.setRepository(mockRepo);

    processor.process(item);

    // Problem: No assertion! Does 'process' do anything? Is item saved?
}

Looks like a test, runs, but proves nothing. And it will be GREEN !! . You gotta check.

Problem #2: Testing the Code You Have, Not the Code You Need (Verification vs. Validation Trap)

This is the deeper problem. Even if an AI test is technically correct for the current code, it might be testing the wrong thing if the code itself is buggy. It's about Verification vs. Validation:

Verification: "Are we building the product right?" Does the code do what the current implementation says it does? AI is okay at this.
Validation: "Are we building the right product?" Does the code actually meet the user's real needs? Does it solve the problem correctly? AI struggles here.

If your calculateTax method has a bug and returns negative tax for some inputs, an AI looking at the code might generate a test asserting that calculateTax(badInput) should return that negative number. It verifies the bug.

Here is a simple example of this buggy method and its AI generated test:

public BigDecimal calculateTax(BigDecimal income) {
   BigDecimal grossTax = income.multiply(TAX_RATE);

   // *** THE BUG IS HERE ***
   // Simple subtraction without checking if the result is negative.
   BigDecimal netTax = grossTax.subtract(STANDARD_DEDUCTION);

   // Rounding for standard currency format (e.g., 2 decimal places)
   return netTax.setScale(2, RoundingMode.HALF_UP);
}

@Test
@DisplayName("Test calculateTax: Should return expected negative tax for low income due to BUG")
void calculateTax_whenIncomeIsLow_shouldReturnNegativeTax_dueToBug() {
  BigDecimal lowIncome = new BigDecimal("10000.00");
  // Expected calculation: (10000 * 0.15) - 5000 = 1500 - 5000 = -3500
  BigDecimal expectedNegativeTax = new BigDecimal("-3500.00");
  BigDecimal actualTax = calculator.calculateTax(lowIncome);
  // We are specifically asserting that the bug produces this negative result.
  assertEquals(expectedNegativeTax, actualTax,
                "BUG CONFIRMATION: calculateTax should return -3500.00 for 10000.00 income");
}

Why?

Code is the Source: The AI learns from the code you give it.
No Requirements Mind-Reading: Without clear, up-to-date requirements, AI doesn't know what the code should do.
It Matches Patterns: It sees input -> process -> output in your code and writes a test for that specific pattern, bug or not.

Let’s see which are the challenges with the validation trap and recommendations to avoid them.

The False Confidence Problem: This is bad. A test passing because of a bug makes everything look green, but the bug is still there, now with a test "protecting" it. Fix the bug later, and the AI's test fails, confusing everyone.

Ignoring Requirements Changes: Requirements evolve. Code written last month might be wrong now. AI testing the code won't know that. It just keeps confirming the potentially outdated behavior.

Analogy: Like spell-checking a document but not fact-checking it. Verification passes, validation fails.

Can AI Test Requirements Directly? Some tools try. You feed them requirements (like Gherkin specs), and they generate tests \cite{aws, visuresolutions, thoughtworks}. Better, but still needs perfect, up-to-date requirements and the AI can still misinterpret them. Many simple AI tools just look at the code.

Consider this buggy code:

// Buggy Implementation
public String formatUsername(String name) {
    if (name == null || name.trim().isEmpty()) {
        return "guest"; // Should maybe throw exception?
    }
    // Bug: Doesn't handle names with spaces well
    return name.toLowerCase();
}

// AI-Generated Test (Based on Buggy Code)
@Test
void whenNameHasSpace_shouldReturnLowerCase() { // Validates bug!
    UserFormatter formatter = new UserFormatter();
    String result = formatter.formatUsername("Test User");
    // AI sees the code returns "test user", so it asserts that.
    // Requirement might be to remove spaces or throw error.
    assertEquals("test user", result);
}

This test passes but locks in the bad behavior of allowing spaces. You, the dev, need to check if the test matches the requirement, not just the buggy code.

So? What to Do? Don't Use AI for Generating Tests? Nah, Rely on Your AI Test Quality Guardian

Given that AI tests can be wonky, using static analysis tools is pretty much essential. These tools automatically scan your code (including tests) against a huge rulebook, finding potential bugs, security issues, and just plain confusing code. When AI is potentially adding lots of code fast, you need this automated check.

Some of these tools even promote AI Code assurance, to keep AI-generated code in check, sometimes with even stricter rules. Makes sense – treat AI code with the same (or more) skepticism as human code.

One of these tools is SonarQube, which has 47 specific rules just for Java tests [https://rules.sonarsource.com/java/tag/tests/]. Let's break down the kinds of issues it catches, with quick examples showing how AI might mess up.

1. Assertions - Did You Actually Check Anything?

Purpose: Ensure tests make meaningful checks. It can be easy to forget assertions and the test will pass making it difficult to spot.
Example (Rule S2699):

// Noncompliant code
@Test
void testAddItem() {
    Cart cart = new Cart();
    Item item = new Item("Thing");
    cart.add(item);
    // Forgot to assert!
}

// Compliant code
@Test
void testAddItem() {
    Cart cart = new Cart();
    Item item = new Item("Thing");
    cart.add(item);
    assertEquals(1, cart.getItemCount()); // Added assertion
}

AI Trap: AI might just call the method and forget the assert.

2. Test Structure, Setup, Teardown - Getting the Basics Right

Purpose: Enforce standard test structure conventions needed by frameworks like JUnit.
Example (Rule S5786):

// Noncompliant code (JUnit 5)
@Test
private void myPrivateTest() { // Test methods shouldn't be private
    assertTrue(true);
}

// Compliant code (JUnit 5)
@Test
void myVisibleTest() { // Default visibility is fine, or public
    assertTrue(true);
}

AI Trap: Generating methods with wrong visibility (private, static) or return types.

3. Naming Conventions - Can Anyone Understand This?

Purpose: Make tests readable and understandable from their names. The BDD convention is widely adopted, but there are others.
Example (Rule S3577):

// Noncompliant code
@Test
void test1() {
    // ... complex setup and assert ...
}

// Compliant code
@Test
void shouldThrowIllegalArgumentException_WhenInputIsNull() {
    // ... clear test logic for null input ...
}

AI Trap: Using generic names like testMethod1 or test_feature_abc.

4. Using Test Frameworks Correctly - JUnit/TestNG Gotchas

Purpose: Ensure proper use of framework features and APIs. Test frameworks provide specific ways of handling different use cases. In this particular case, exceptions.
Example (Rule S5776):

// Noncompliant code (JUnit 5) - Old way to check exceptions
@Test
void testDivisionByZero_OldWay() {
    Calculator calc = new Calculator();
    try {
        calc.divide(1, 0);
        fail("Should have thrown ArithmeticException");
    } catch (ArithmeticException expected) {
        // Expected exception caught, test passes implicitly
    }
}

// Compliant code (JUnit 5) - Using assertThrows
@Test
void testDivisionByZero_NewWay() {
    Calculator calc = new Calculator();
    assertThrows(ArithmeticException.class, () -> {
        calc.divide(1, 0);
    });
}

AI Trap: Using outdated patterns (like the try/catch/fail for exceptions) or mixing framework versions.

5. Performance and Resource Usage - Don't Slow Down the Build

Purpose: Avoid bad practices like printing to console or leaking resources in tests. It is not easily configurable, can mess with build tools and it’s a sync process that will slow down the build.
Example (Rule S106):

// Noncompliant code
@Test
void testSomethingComplex() {
    // ... logic ...
    System.out.println("Debug: Intermediate value = " + value); // Avoid this
    // ... asserts ...
}

// Compliant code
@Test
void testSomethingComplex() {
    // ... logic ...
    log.debug("Debug: Intermediate value = " + value);
    // ... asserts ...
}

AI Trap: Leaving System.out.println calls used during generation/debugging.

6. Mocking Frameworks - Using Mocks Correctly

Purpose: Guide correct usage of mocking frameworks like Mockito, specially on the setup phase. If not done correctly can lead to unexpected issues.
Example (Rule S5979):

// Noncompliant code (Potential Issue: Forgetting to mock)@Testvoid testServiceUsingRepository() {
    // Missing mock setup for repository dependency
    MyRepository repo; // = mock(MyRepository.class);
    MyService service = new MyService(repo); // Might throw NPE if repo is null
    service.doWork();
    // Assertions might fail unpredictably
}

// Compliant code (Basic Mocking)
@Test
void testServiceUsingRepository() {
    MyRepository repo = mock(MyRepository.class); // Mock dependency
    when(repo.getData()).thenReturn("mock data"); // Stub method call
    MyService service = new MyService(repo);
    service.doWork();
    verify(repo).getData(); // Verify interaction
    // Add assertions based on service logic
}

AI Trap: Generating incomplete mock setups or incorrect verification logic.

7. Exception Handling - Be Specific

Purpose: Ensure tests checking for exceptions look for the specific expected exception. Generic exceptions can swallow several different use cases, and the code should catch those exceptions types that can handle.
Example (Rule S112):

// Noncompliant code
@Test
void testInvalidInput() {
    Processor processor = new Processor();
    // This is too broad, might catch unexpected runtime exceptions
    assertThrows(Exception.class, () -> {
        processor.process(null);
    });
}

// Compliant code
@Test
void testInvalidInput() {
    Processor processor = new Processor();
    // Be specific about the expected exception
    assertThrows(IllegalArgumentException.class, () -> {
        processor.process(null);
    });
}

AI Trap: Using generic Exception when a more specific one is appropriate.

Seeing these examples shows how easy it is for generated code (and human code!) to violate basic testing hygiene. SonarQube acts as your automated checklist for this stuff.

How to Use AI Test Tools Without Getting Burned

So, how do you actually use these tools without causing chaos?

Human Review is Mandatory (Really!): Never skip this. Check if the test makes sense, if the asserts are good, if it tests the requirement, if it covers edge cases, and if your static analysis guardian is happy.
Use Static Analysis Everywhere: Put a linter in your IDE. Put it in your CI pipeline. Fail the build if quality drops. Make it non-negotiable.
Let AI Do the Easy Stuff: Don't expect miracles. Use AI for:
- Boilerplate: Test methods, basic setup/teardown.
- Simple Mocking: Basic when/thenReturn.
- Test Variations: Generating different inputs for a test you already wrote and trust.
Give Better Instructions: Garbage prompts = garbage tests.
- Add Context: Give it docs, requirements snippets, good examples.
- Be Specific: Tell it exactly what to test, what to mock, what to assert.
Iterate: Treat the AI output as a first draft. Review, fix, improve.
Learn the Tools: Figure out how your specific AI tool works best. Practice prompting. Learn to spot its common mistakes quickly.
Start Small: Try it on a safe project first. See if it really saves time after you account for fixing its output.

Wrapping Up

AI test generation? It's here and it can write test code fast, which is cool. But don't just trust it blindly. AI often gets things wrong, misses assertions, or writes tests that just confirm your bugs are still there.

Think of AI as a helper, not the expert 🧙. Let it write first drafts or boring bits. But you need to review everything. Does it test the actual requirement? Is the logic sound? Use static analysis to automatically check for common mistakes in your pipeline. Keep your brain engaged, and you can probably get some real speed benefits from AI without sacrificing quality.

TDD & Human created tests are dead: Long live AIDD

Jonathan Vila — Wed, 26 Feb 2025 10:40:27 +0000

Software testing has traditionally been a human-centric task. Quality Assurance (QA) engineers meticulously craft test cases, execute them, and analyze the results. Developers, in the classic approach, generate the tests to check their code, or in a more advanced and mature approach, they start by creating the tests and evolve the code from there (TDD).

This process, while effective, is time-consuming and prone to human error. However, the advent of artificial intelligence (AI) is poised to revolutionize this landscape.

The Rise of AI in Software Development

AI is already making significant inroads into software development. As highlighted in the article "Code Reviews with AI: a Developer Guide" AI-powered tools assist with code generation, review, and optimization. This integration of AI is not limited to development; it's also transforming the testing phase.

AI-Generated Test Cases: A New Paradigm

A thought-provoking idea is emerging: AI will generate test cases directly from Jira tickets and specifications documentation considering the current code. This concept challenges the traditional notion that test creation is a solely human task or that AI can assist in test generation by just looking at the code to test.

AI, with its ability to analyze requirements and specifications, can potentially generate comprehensive and relevant test cases, reducing the manual effort involved.

However, there's a potential for low-quality tests that merely test the code generated (sometimes by AI) and do not consider the human definition of the task and use cases to test.

Continuous Testing with AI

Furthermore, AI can enable continuous testing throughout the development process. As code is written and modified, AI can automatically generate and execute tests, providing real-time feedback on code accuracy. This "shift-left" approach to testing can identify defects early, reducing the cost and effort of fixing them later.

Challenging the Status Quo

This AI-driven testing approach challenges established practices like Test-Driven Development (TDD), where tests are written before the code. TDD ensures that the application code is constantly tested, and only the code needed is created.

Code generated with AI can also be guided by requirements and specifications, with application code focused on meeting those requirements and tests generated automatically to validate the code against those specifications.

GenAI tools can utilize internal company data as contextual input. Agents and supporting tooling are employed to ingest, parse, and understand a variety of data sources, including Jira tickets, Google Docs, and Slack conversations, among others. This enables the AI to construct a comprehensive operational context.

AI MCP provides a standardized protocol that facilitates agent-to-connector communication. This allows agents to query and retrieve information from diverse data sources, effectively building contextual awareness. Additionally, the protocol supports data transformation, ensuring that retrieved information is formatted for optimal consumption by the GenAI system.

List of MCP Servers and Cursor IDE using MCP server

Benefits of AI-Driven Testing

The potential benefits of AI-driven testing are substantial:

Increased Efficiency: AI can generate tests faster than humans, accelerating the testing process.
Improved Test Coverage: AI can analyze code and requirements to identify potential test scenarios that humans might miss, leading to better test coverage.
Reduced Human Error: AI can eliminate errors that humans might introduce during test creation and execution.
Faster Feedback: AI-powered continuous testing provides real-time feedback, enabling developers to address issues quickly.

But, Is it really as good as it seems?

While AI-driven development holds immense promise, it also presents challenges. Ensuring the accuracy and reliability of AI-generated test cases is crucial. Additionally, the role of QA engineers will need to evolve, focusing on overseeing AI-driven testing processes and interpreting results.

AI is undoubtedly beneficial and is getting better and better. Still, to have the perfect solution, human intervention is required to sign off that the produced artifact meets the company and quality standards. This human intervention can be helped by tools that will analyze the code produced and check for code quality by detecting any maintainability issues, security hotspots, and vulnerabilities. It’s crucial to have a good analyzer tool in our Swiss knife.

Conclusion

AI is set to reshape software testing, much like it's transforming other aspects of software development. The idea of AI-generated test cases and continuous testing represents a significant shift in how we approach quality assurance.
Embracing this AI-driven future with the help of static analysis tools will be key to delivering high-quality software efficiently and effectively.

Code Reviews with AI: a Developer Guide

Jonathan Vila — Tue, 18 Feb 2025 18:08:17 +0000

Code reviews are a cornerstone of software development. They're where we share knowledge, catch bugs early, and ensure our code meets the highest standards.

But let's be honest...

Traditional code reviews can be time-consuming and tedious and sometimes even miss subtle yet critical issues. Enter the age of AI-powered code review, a game-changer that addresses these challenges and elevates code quality to new heights.

This article dives into the common pitfalls of code reviews and explores how AI tools can revolutionize each phase of the development lifecycle.

I will discuss the use and impact of AI on the different phases of the SDLC from the 2 main perspectives of the developer and the reviewer. I will also talk specifically about the use of AI in the Code Review and how to implement it productively. I will provide examples of tools used in the different phases: Github Copilot, SonarQube, Qodo, and IntelliJ.

Code generated by AI code assistants

AI-powered generative code assistants take the power of AI even further by automatically generating code based on your inputs. This can dramatically reduce the time and effort required to write code, especially for repetitive or boilerplate tasks.

Generative code assistants can also help you explore different design options and identify potential problems before you start coding. By leveraging these tools, you can focus on the creative and strategic aspects of software development, while the AI handles the tedious and mechanical tasks.

AI adoption

There’s a long list of AI code assistants providing different features, with different ranking rates considering 5 different categorizations:

https://research.aimultiple.com/ai-coding-benchmark/

While these tools are powerful and feature-rich, they rely on models hosted somewhere and there is a price involved in some of the features.

The local free open-source approach ....

Other completely open-source options are also available. This option involves hosting the model to generate code locally or in your network. There are tons of free and open-source models that you can use, and you can only serve those models by installing the free tool Ollama on a machine in your network or locally.

I’ve tried with the IntelliJ plugin “Continue”, Ollama, and the models “codellama” and ”deepseek-coder” and the experience was not bad at all. With this solution also you are sure your code, and your prompts are not going anywhere out of your domains.

But, every magic comes with a price.

While generative AI holds immense promise, it is not without its pitfalls. One major concern is the potential for introducing bugs and vulnerabilities into code. AI models are trained on vast amounts of data, and if this data contains errors or malicious code, the generated code may inherit these flaws.

AI-generated code correctness

Additionally, generative AI systems may not fully understand the context or intent of the code they generate, leading to nonsensical or even harmful output. Furthermore, there is a risk that generative AI could not use the full code base context in order to generate the most aligned code with our current content. It is crucial for developers to carefully review and test code generated by AI and to employ robust security measures to mitigate these risks.

With this panorama, it’s clear that using AI to generate code will impact positively the speed, but also negatively in the full SDLC and more importantly in the code review process.

Let’s focus on the traditional code review process and its pain points.

The Traditional Code Review Struggle: Familiar Pain Points

We've all been there. Traditional code reviews, while valuable, often suffer from:
● Time Consumption: Manually reviewing every line of code is a significant time investment, especially for large projects.
● Subjectivity: "Good code" can be subjective, leading to inconsistencies in feedback and potential disagreements.
● Missed Issues: Even the most experienced human reviewers can miss subtle bugs, security vulnerabilities, or performance bottlenecks. We’ve seen from above how code assistants can
impact here.
● Focus on Style: Too much emphasis on minor stylistic issues can distract from more critical problems.
● Lack of Context: Reviewers may lack the full context of the code changes, making it harder to provide effective feedback.
● High Cognitive Load: Reviewing large pull requests with hundreds of lines of code can overwhelm even the most experienced developers.
● Delayed Feedback: Waiting for a code review can slow the development pipeline, impacting delivery timelines.
● Team friction: Code reviews can lead to team friction when simple issues are overlooked due to a lack of context, when subjective feedback occurs, or when poor feature testing occurs, potentially escalating into disagreements.

AI to the Rescue: Enhancing Code Reviews

AI-powered tools are transforming code reviews by automating tedious tasks, providing objective feedback, and uncovering hidden issues. Let's explore how these tools can assist throughout the development lifecycle:

1. Development Phase (IDE Integration)

We’ve seen that several code assistant plugins and IDEs can help us generate code. Several benchmarks (huggingface, stackeval, Mike Ravkine’s) could help us choose the model to use in those assistants.

So, we have the proper tools for auto-completion and code generation, but what about verifying that the code generated does not introduce issues, vulnerabilities, or solutions that are not well suited for the language version of the code base context?

For this task, there are static analyzers in the form of IDE linters, like SonarQube for IDE, that will provide instant feedback as you write code, or CI/CD code analyzers, like SonarQube Server/Cloud, which will do a full analysis of your code and prevent or allow it to be merged.

Imagine catching potential bugs and best practices before they even make it to a code review.

These linters use static analysis, and different functions, to detect code smells, bugs, and security vulnerabilities directly in your IDE, empowering you to write cleaner and safer code from
the start.

However, this includes not only bugs and vulnerabilities but also best practices for using certain frameworks or language versions. AI code assistants sometimes are not well aware of the language version that you are using (e.g., Java 21) in your codebase, and the solutions they suggest do not consider the latest improvements in the language, just simply the most used approaches.

In this case, GitHub Copilot didn’t suggest an approach using a feature introduced 7 years ago.

Generated by Github Copilot

public double calculateAverage(Collection<Integer> collection) { 
   int sum = 0; 
   for (Integer num : collection) { 
       sum += num; 
   } 
   return (double) sum / collection.size(); 
}

Manual approach considering Java's new Teeing collector, introduced in Java 12, using the consisted and language level approach to iterate collections and lazily compute values from it.

public double calculateAverageManual(Collection<Integer> collection) { 
   return collection.stream().collect( 
Collectors.teeing( 
             Collectors.summingDouble(i -> i), 
             Collectors.counting(), 
             (sum, count) -> sum / count) 
); 
}

or even not using the latest new features of a language. In this case, Virtual Threads were introduced in Java 21, a year and a half ago.

Code generated by Github Copilot, using platform threads

new Thread(() -> { 
   var url = new URI("http://localhost:4000").toURL(); 
   var connection = (HttpURLConnection) url.openConnection(); 
   connection.setRequestMethod("GET"); 
   int responseCode = connection.getResponseCode(); 
}).start();

Manual approach using Virtual Threads, being able to create thousands of threads that will increase the performance dramatically in blocking operations.

Thread.ofVirtual().start(() -> { 
   var url = new URI("http://localhost:4000").toURL(); 
   var connection = (HttpURLConnection) url.openConnection(); 
   connection.setRequestMethod("GET"); 
   int responseCode = connection.getResponseCode(); 
}).start();

Luckily these linters will also warn us about the lack of best practices usage while we code and during the CI full analysis.

A particular benefit of some linters over others (like SonarQube IDE) is that they can analyze multiple types of files at the same time in the same project. This is not only restricted to programming languages like Java, Python, JScript, Kotlin, etc. but also to Cloud deployment files like Docker, Kubernetes, Ansible, Terraform, CloudFormation, etc., and even Secrets vulnerabilities.

2. Test generation Phase

AI can analyze current code, try to understand its purpose, and generate test methods that will potentially generate the test code, ensuring high coverage. This helps to ensure that your code is thoroughly tested before it is released.

In this area, we can find tools like Qodo Gen, among others, that specialize in test generation.

I’ve installed it in my IntelliJ IDE and tried it with my AI project. The result is impressive, considering several test use cases in the happy path or edge cases. As with most code assistants, we can select which remote-hosted model we want to use.

Tools like Qodo will take a class method and create its tests. We will have a dashboard to see the tests and executions, and also a plan for the test generation in the Qodo plugin :

3. Pull Request creation

The process of creating a Pull Request is also important in order to give the proper context and details to those who will review it.

A typical workflow would usually imply:

● Follow the initial process of joining/sign-in a team
● Read the contribution guidelines
● Do the commits following a convention
● Sign all the commits (please!)
● Create a draft pull request with a good and complete description (sometimes following a template e.g. JKube project)
● Wait for all the checks to pass
● Change the PR status to ready to review.

Several guides (GitHub, pull request) can help you write good descriptions, but we can leverage AI for this. One of the tools we can use for this is Github Copilot, which analyzes the code in the PR to provide a more detailed description.

In these two images, we see how we can ask Github Copilot to generate a summary for the PR.

We can also expand this with all the details we think can add more context and value and help reviewers in their tasks.

4. Pre-Code Review (Automated Analysis)

Static analyzers (like SonarQube) perform in-depth static analysis on your codebase, identifying issues that might be missed by human reviewers. This goes beyond style checks and delves into:

● Bug Detection: Identifying potential NullPointerExceptions, logic errors, and other bugs.
● Security Vulnerabilities: Detecting potential injection attacks, cross-site scripting (XSS) vulnerabilities, and other security risks.
● Code Smells: Highlighting code that is difficult to read, maintain, or understand. For example, overly complex methods or duplicated code.
● Code Coverage: Measuring the percentage of code covered by unit tests, helping to ensure comprehensive testing.

These analyzers present these issues clearly and actionably, prioritizing them based on severity.

This allows developers to focus on the most critical problems first, making the review process more efficient and effective.
Connecting this step with the previous PR workflow, the tools we connect to our repository can help us to check for all the scenarios that can make our code fail, before anyone invests time in reviewing it, to just focus on working changes that need experienced review.

5. Pull Request changes explanation

Now it’s the turn of the reviewers. They should start by reading the ticket that defines the PR's goal. After that, a careful review of the checks' status will give us an idea of whether the changes are okay to be merged.

For this, we can use several tools. I’ve tried Github Copilot and Qodo PR-Agent (you can find a comparison here) :

While Copilot has an explanation feature per changed file, Qodo can create a description for the entire PR. This will help the reviewers understand the details applied to files and focus on those that require more attention. It’s important to reduce the time a PR needs to be merged, and definitely, the usage of AI tools can help us with that.

6. Changes suggestion

In some PRs, reviewers make suggestions to improve or fix parts of the document. This is a crucial point that, if not done correctly, can add anxiety and friction among team members.

There are some guidelines in order to have safe and productive communication between the author and reviewers.

Some AI tools, like Qodo PR-Agent, can also implement the improvements and changes suggested by the AI agent directly from the PR review to the code.

Like all the changes, they need to be analyzed and checked with tools like SonarQube. If there are any issues, these tools will fail, preventing those changes from being merged into the main branch.

Addressing the Challenges with AI

Here's how AI tackles the traditional code review challenges:

● Reduced Time: Automation frees up developers to focus on more complex and creative tasks. Also helps reduce the cognitive load for the review process needed to understand the scope of all the changes.
● Increased Objectivity: Static analysis provides objective, consistent, and deterministic feedback based on predefined rules and best practices.
● Focus on Critical Issues: Prioritization helps reviewers focus on the most important problems.
● Enhanced Context: AI can read the changes and generate meaningful PR descriptions
along with detailed explanations of the changes for the reviewers.

Conclusion

AI is not replacing human reviewers; it's empowering them. By automating tedious tasks and providing valuable insights, AI tools will improve the speed and comprehension of the generated code.

Tools like static analyzers will automatically check code compliance and guarantee code quality throughout the SDLC, allowing developers to focus on what they do best: designing, building, and innovating.

By leveraging AI-powered tools, we can shift our focus from simply finding bugs to building high-quality, maintainable, and secure software.

Code Quality in the Cloud

Jonathan Vila — Fri, 20 Dec 2024 08:41:26 +0000

Infrastructure as Code (IaC) has transformed how you deploy and manage cloud infrastructure. Tools like Azure Resource Manager, AWS CloudFormation, Docker, Kubernetes, Ansible, and Terraform have made deploying infrastructure faster and more scalable. However, they’ve also introduced a new set of security challenges.

In recent years, there have been numerous security incidents caused by IaC misconfigurations. These include:

Open Ports and Weak Security Groups: Exposing cloud resources to the public internet.
Hardcoded Secrets: Credentials, API keys, or sensitive data embedded in code.
Overly Permissive Policies: Granting unnecessary privileges to users or services.
Missing Resource Limits: Allowing unrestricted use of cloud resources, leading to potential outages or abuse.

The consequences of these issues can be severe, from data breaches to financial loss and reputational damage. Moreover when Code GenAI is used in order to produce those artifacts.

Code GenAI is a great help to start code artifacts and produce boilerplate code, but it also needs to be reviewed to avoid the introduction of unexpected issues and vulnerabilities.

Fortunately, there are tools that can help identify critical vulnerabilities early in development.

From the SonarQube Cloud telemetry, I've gathered the most hit issues regarding IaC, with more than 6 million hits in total across all projects analyzed.

In this article, I focus on Azure, CloudFormation, Docker, Kubernetes, Ansible and Terraform as examples of IaC issues. I highlight each critical issue, its risks, and how to fix it.

As a bonus chapter, you can see the result of an experiment with Code GenAI using different providers to generate Kubernetes artifacts and check if they are as clean and secure as we expect.

Let's start with a list of examples of all the IaC artifacts covered in this article (and supported by SonarQube).

Azure Resource Manager

Restrict Public Access to Resources

Problem: Allowing unrestricted public access to Azure resources (e.g., Blob Storage) exposes them to unauthorized users.

Solution: Using publicNetworkAccess to control access to resources.

{
  "type": "Microsoft.Web/sites",
  "apiVersion": "2020-12-01",
  "name": "example-site",
  "properties": {
     "siteConfig": {
        "publicNetworkAccess": "Disabled"
     }
  }
}

AWS CloudFormation

1. Ensure S3 Buckets Are Private

Problem: Publicly accessible S3 buckets can lead to data leaks.

Solution: Set the bucket's AccessControl to Private.

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: Private

2. Apply Least Privilege to IAM Roles

Problem: Granting broad permissions creates unnecessary security risks.

Solution: Limit actions and resources to only what’s required.

Resources:
  # Update Lambda code
  lambdaUpdatePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: lambdaUpdatePolicy
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Action:
              - lambda:UpdateFunctionCode
            Resource: "arn:aws:lambda:us-east-2:123456789012:function:my-function:1"

Docker

Avoid Running Containers as Root

Problem: Running containers as root increases the risk of privilege escalation.

Solution: Create and use a non-root user in your Dockerfile.

FROM alpine

RUN addgroup -S nonroot \
    && adduser -S nonroot -G nonroot

USER nonroot

ENTRYPOINT ["id"]

Kubernetes

1. Don’t Run Privileged Pods

Problem: Running containers in privileged mode can reduce the resilience of a cluster in the event of a security incident because it weakens the isolation between hosts and containers.

Solution: Disable privileged mode in your pod specification.

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
      securityContext:
        privileged: false

2. Define Resource Requests and Limits

Problem: Allowing pods to use unlimited resources can destabilize the cluster.

Solution: Specify resource requests and limits for containers.

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: app
      image: myapp:latest
      resources:
        requests:
          memory: "256Mi"
          cpu: "0.5"
        limits:
          memory: "512Mi"
          cpu: "1"

3. Specific version tag for image should be used

Problem: When a container image is not tagged with a specific version, it is referred to as latest. This means that every time the image is built, deployed, or run, it will always use the latest version of the image.

Solution: To avoid these issues, it is recommended to use specific version tags for container images.

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2 

    - name: nginx
      image: nginx@sha256:b0ad43f7ee5edbc0effbc14645ae7055e21bc1973aee5150745632a24a752661

Terraform

Allowing public network access to cloud resources is security-sensitive

Problem: Enabling public network access to cloud resources can affect an organization’s ability to protect its data or internal operations from data theft or disruption.

Solution: Use private networks and VPC peering or other secure communication tunnels to communicate with other cloud components.

resource "google_compute_instance" "example" {
  network_interface {
    network = google_compute_network.vpc_network_example.name
  }
}

Ansible

1. Server certificates should be verified

Problem: This vulnerability makes it possible for encrypted communication to be intercepted.
Solution: Ensure playbooks do not bypass certificate validation.

- name: Example playbook
  hosts: server
  tasks:
    - name: Retrieve a web page
      ansible.builtin.uri:
        url: https://www.example.com
        validate_certs: true
        return_content: true

2. Loose POSIX permissions

Problem: Files with overly permissive POSIX permissions (e.g., 777) grant unnecessary read, write, or execute access to unauthorized users.
Solution: Ensure playbooks explicitly set restrictive permissions on sensitive files.

- name: My deployment
  hosts: all
  tasks:
    - name: Create /etc/demo with permissions
      ansible.builtin.file:
        path: /etc/demo
        state: directory
        mode: '0770'

    - name: Copy demo3.conf and set symbolic permissions
      ansible.builtin.copy:
        src: /files/demo.conf
        dest: /etc/demo/demo.conf
        mode: 'g=r,u+w,o='

Secrets management

Keys and passwords being disclosed

Problem: Secret leaks often occur when sensitive authentication data is stored with an application's source code. This is one example (OVH keys, the most hit issue) but the issue extends to several platforms.

props.set("ovh-key", "EXEgWIz07P0HYwtQDs7cNIqCiQaWSuHF")

Solution:

props.set("ovh-key", System.getenv("OVH_KEY"))

Experimenting with Code GenAI and IaC

In order to see how accurate is Code GenAI for IaC artifacts, I've done an experiment with an AI application made in Java using Qarkus. You can find the source code here.

Using my IDE I've asked two different code assistants to produce the Kubernetes Deployment yaml file to deploy the application.

I've used Github Copilot and Amazon Q as code assistants.
Let's see the results.

Github Copilot

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pingpong-ai-deployment
  labels:
    app: pingpong-ai
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pingpong-ai
  template:
    metadata:
      labels:
        app: pingpong-ai
    spec:
      containers:
        - name: pingpong-ai-container
          image: your-docker-repo/pingpong-ai:latest
          ports:
            - containerPort: 8080
          env:
            - name: QUARKUS_PROFILE
              value: prod
            - name: JAVA_OPTS
              value: "-Dquarkus.http.host=0.0.0.0"
          volumeMounts:
            - name: config-volume
              mountPath: /deployments/config
      volumes:
        - name: config-volume
          configMap:
            name: pingpong-ai-config
---
apiVersion: v1
kind: Service
metadata:
  name: pingpong-ai-service
spec:
  selector:
    app: pingpong-ai
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

It has been smart enough to generate a Service and a volume. But, not all is shiny. SonarQube for IDE has detected 6 issues :

Amazon Q

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application
  labels:
    app: my-application
spec:
  replicas: 3  # Number of pod replicas you want to run
  selector:
    matchLabels:
      app: my-application
  template:
    metadata:
      labels:
        app: my-application
    spec:
      containers:
        - name: my-application
          image: your-registry/your-image:tag  # Replace with your image
          ports:
            - containerPort: 8080  # Replace with your application port
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          env:
            - name: ENVIRONMENT
              value: "production"
          # Add any environment variables your application needs
          livenessProbe:
            httpGet:
              path: /health  # Replace with your health check endpoint
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health  # Replace with your health check endpoint
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

This output is way cleaner and of higher quality than the previous one, and SonarQube for IDE has detected only 2 issues. However, it doesn't provide a Service or a volume for configuration files.

In both cases, it's been fast and without the problem of typing errors (wrong attribute name, wrong number of spaces, tabs, etc..)., but as with any code generated by AI, it needed a review phase to detect issues that are not always obvious in order to submit good-quality code to our repository and lead to smooth Pull Request reviews.

Conclusion

IaC enables teams to automate and scale infrastructure efficiently, but with great power comes great responsibility. Misconfigurations, hardcoded secrets, and overly permissive access controls are common mistakes that can lead to serious security vulnerabilities.

By following best practices and leveraging tools like SonarQube, developers can identify and resolve critical security issues early in the development process.

More than just security, maintaining code quality in IaC is essential. Well-structured, maintainable IaC ensures teams can quickly adapt to new requirements and maintain a robust, secure infrastructure.

Combining high-quality code with automated tooling is the key to avoiding costly security mishaps. SonarQube has rules to check all these issues in Azure Resource Manager, Docker, Kubernetes, CloudFormation, Terraform, Ansible and Secrets in general.

Building local LLM AI-Powered Applications with Quarkus, Ollama and Testcontainers

Jonathan Vila — Tue, 10 Dec 2024 15:39:54 +0000

Traditionally, many AI-powered applications rely on cloud-based APIs or centralized services for model hosting and execution. While this approach has its advantages, such as scalability and ease of use, it also introduces challenges around latency, data privacy, and dependency on third-party providers.

This is where local AI models shine. By running models directly within your application's infrastructure, you gain greater control over performance, data security, and deployment flexibility. However, building such systems requires the right tools and frameworks to bridge the gap between traditional software development and AI model integration.

In this article, we explore how to combine Quarkus, a modern Java framework optimized for cloud-native applications, with Ollama, a platform for running AI models locally. We’ll also demonstrate how tools like Testcontainers and Quarkus Dev Services simplify development and testing workflows. Using the PingPong-AI project as a practical example, you'll learn how to build and test AI-driven applications that harness the power of local models.

The PingPong-AI project demonstrates a simple implementation of AI-powered functionality using Quarkus as the backend framework and Ollama for handling AI models. Let’s break down the architecture and walk through key components of the code.

Project Overview

In PingPong-AI, Ollama is used to simulate a simple conversation model where a curious service generates questions around a topic and a wise service responds with informated answers, that will generate more questions on the curious service.

The project integrates Quarkus with Ollama to create an AI model-driven application. It leverages Quarkus's lightweight and fast development model to serve as a backend for invoking and managing AI interactions. Here's an overview of what we'll cover:

Integrating Quarkus with Ollama
Using Testcontainers for Integration Testing
Leveraging Quarkus Dev Services for Simplified Development

1. Integrating Quarkus with Ollama

Why Ollama?

Ollama simplifies the deployment and use of AI models in applications. It provides a runtime for AI model execution and can be easily integrated into existing applications.

Quarkus and Ollama Integration

The integration with Quarkus is handled using REST endpoints to interact with Ollama. The Quarkus application serves as the middleware to process client requests and communicate with the Ollama runtime.

Here’s a snippet from PingPongResource.java, which defines the REST endpoint for the PingPong interaction:

@Path("/chat")
public class CuriousChatResource {
    @Inject
    CuriousService curiousService;

    @Inject
    WiseService wiseService;

   @POST
    @Produces(MediaType.TEXT_PLAIN)
    @Consumes(MediaType.TEXT_PLAIN)
    @Path("/{numberOfQuestions}")
    public String chat(@PathParam("numberOfQuestions") Integer numberOfQuestions, String topic) {
        StringBuilder sb = new StringBuilder();
        sb.append("> Topic: ").append(topic).append("\n");
        while (numberOfQuestions-- > 0) {
            String question = curiousService.chat(topic);
            sb.append("> Question: ").append(question).append("\n");
            topic = wiseService.chat(question);
            sb.append("> Answer: ").append(topic).append("\n");
        }

        return sb.toString();
    }
}

In this code:

The CuriousChatResource handles client POST requests.
The injected CuriousService and WiseService interface with the Ollama runtime to process the message.

These Ollama services are responsible for calling the Ollama runtime. Here's a snippet from CuriousService.java:

@RegisterAiService
@SystemMessage("You are a curious person that creates a short question for every message you receive.")
public interface CuriousService {
    public String chat(@UserMessage String message);
}

We can even use different models for each service, specifying the configuration property that identifies the model. This example comes from CuriousService.java:

@RegisterAiService(modelName = "curiousModel")

And we identify the model in application.properties :

quarkus.langchain4j.ollama.wiseModel.chat-model.model-id=tinydolphin
quarkus.langchain4j.ollama.curiousModel.chat-model.model-id=tinyllama

2. Using Testcontainers for Integration Testing

Why Testcontainers?

Testcontainers is a Java library for running lightweight, disposable containers during tests. In PingPong-AI, Testcontainers are used to set up an environment with an Ollama runtime for integration testing.

Example: Setting up a Testcontainer for Ollama

The test class demonstrates how to configure and use Testcontainers:

@QuarkusTest
class CuriousChatResourceTest {
    @Inject
    CuriousService curiousService;

    @Inject
    WiseService wiseService;

    @Test
    @ActivateRequestContext
    void testFXMainControllerInteraction() {

        // Perform interaction and assertions
        var curiousAnswer = curiousService.chat("Barcelona");
        var response = wiseService.chat(curiousAnswer);

        Log.infof("Wise service response: %s", response);
        // Using llama2 model we can check if the response contains 'Barcelona', but not
        // with tinyllama
        assertFalse(response.isEmpty(), "Response should not be empty");
    }
    @Test
    @ActivateRequestContext
    void testChatEndpoint() {
        given()
            .when()
                .body("Barcelona")
                .contentType(ContentType.TEXT)
                .post("/chat/3")
            .then()
                .statusCode(200)
                .contentType(ContentType.TEXT)
                .body(not(empty()))
                .body(org.hamcrest.Matchers.stringContainsInOrder("Question:", "Answer:", "Question:", "Answer:", "Question:", "Answer:"));

    }
}

Key Points:

The @QuarkusTest annotation allows Quarkus to run the application in a test-friendly mode.
Quarkus finds a service (Ollama) for which it needs an instance and it will spin up a container for that.

3. Leveraging Quarkus Dev Services for Ollama

What Are Quarkus Dev Services?

Quarkus Dev Services simplifies the setup of required services during development. For this project, Quarkus Dev Services can spin up an Ollama runtime container automatically.

Configuring Dev Services

The application.properties file includes configurations for enabling Dev Services:

quarkus.langchain4j.ollama.chat-model.model-id=tinyllama
quarkus.langchain4j.ollama.devservices.model=tinyllama
quarkus.langchain4j.log-requests=true

With these configurations, Quarkus Dev Services automatically starts an Ollama container when the application is run in development mode or in test, removing the need for manual setup.

Development Workflow

You can launch the application in development mode using the following command:

./mvnw quarkus:dev

This command:

Starts the Quarkus application.
Automatically sets up an Ollama runtime container.
Enables hot-reloading for rapid development.

Conclusion

The PingPong-AI project demonstrates a seamless integration of Quarkus with Ollama, making it easy to build AI-powered applications. By leveraging Testcontainers and Quarkus Dev Services, developers can efficiently test and develop their applications in a containerized and automated environment.

Key Takeaways:

Quarkus provides a lightweight framework for building and deploying Java applications.
Ollama simplifies AI model integration with backend systems.
Testcontainers and Dev Services streamline the testing and development workflows.

To explore this project further, check out the PingPong-AI GitHub repository.

Building an AI Fix SonarQube Dashboard with Vaadin and Spring Boot

Jonathan Vila — Mon, 02 Dec 2024 14:35:19 +0000

SonarQube provides developers with static code analysis capabilities, allowing teams to identify and resolve code quality issues. It also includes an AI Fix feature that helps developers fix specific issues using the full power of AI.

The project sonarqube-bulk-ai-fix shows how to focus only on those issues with AI fixes as an example of how to easily connect to SonarQube Server API and show the fixes in SonarQube IDE.

In this article, we’ll explore how the project leverages the SonarQube API alongside Vaadin and Spring Boot to create an intuitive dashboard for AI fixing code issues.

Why SonarQube API?

SonarQube’s API provides extensive capabilities to interact with its core features programmatically, enabling:

Fetching project and issue data
Managing quality gates and rules
Integrating with CI/CD pipelines

This project highlights the use of the API to identify issues and seamlessly process AI fixes. Let's examine the technical components.

Overview of the Architecture

The project architecture integrates:

Spring Boot: Acts as the backend to manage business logic and handle API interactions.
Vaadin: Provides a modern, web-based UI for the dashboard.
SonarQube API: Fetches project issues and applies fixes programmatically.

Prerequisites

SonarQube Server / SonarQube Cloud instance running with AI CodeFix feature enabled (> 10.7)
IDE running (VSCode, IntelliJ)
Container runtime (Podman, Docker)

Running SonarQube Server

If you don't have access to a SonarQube Cloud instance with CodeFix feature enabled, you can try this example locally. To do that,request an Enterprise free trial license.

The next step is to create a docker-compose file to have persistence in our analysis, otherwise, it would use a memory database, and every time you run the container, it will be empty.

version: "3"

services:
  sonarqube:
    image: sonarqube:enterprise
    depends_on:
      - db
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: sonar
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
      - ~/cacerts:/opt/java/openjdk/lib/security/cacerts
    ports:
      - "9000:9000"
  db:
    image: postgres:latest
    environment:
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:
  postgresql:
  postgresql_data:

And finally, run SonarQube with this command :

docker-compose -f ./docker-compose-sonarqube-postgre.yaml up

After a few seconds, you can open our browser on localhost:9000 and specify the new password (the default is admin/admin).
Now you should paste the contents of the trial license file we received and Voila!

Analysing our first project

In order to test the connection with real data, you would need to incorporate a project analysis in the SonarQube dashboard. To do this for a given Java project simply run this command in the project folder (considering it's a Maven Java application):

mvn clean verify sonar:sonar -Dsonar.projectKey=sample -Dsonar.host.url=http://localhost:9000 -Dsonar.login=admin -Dsonar.password={replace with your pass}

Using the SonarQube API

The first step is connecting to the SonarQube API to retrieve and manipulate issue data. In the project, a SonarQubeClient class encapsulates this functionality.
There are some API calls supported by the Sonar SDK, and others that are direct calls using HttpClient.

To find out which API endpoints and types are supported, go to Web API and Web API v2.

Sonar API Client in Spring Boot

You can use the sonar-ws SDK to connect to SonarQube and get the issues for a given filter.
We need to use pagination, as it's only returning 100 elements per query.

    public SearchWsResponse getListOfIssues(String project, String page, String pageSize) {
        // Call the SonarQube API to get the issues
        var httpConnector = HttpConnector.newBuilder()
                .url(filter.sonarqubeUrl())
                .credentials(filter.sonarqubeUser(), filter.sonarqubePassword())
                .build();
        var wsClient = WsClientFactories.getDefault().newClient(httpConnector);
        var issueRequest = new SearchRequest();
        issueRequest.setProjects(Collections.singletonList(project));
        if (filter.severity() != null) {
            issueRequest.setSeverities(List.of(filter.severity()));
        }

        issueRequest.setP(page);
        issueRequest.setPs(pageSize);
        return wsClient.issues().search(issueRequest);
    }

To check if an issue has an AI Code Fix, you need to make a direct call using the HttpRequest object because the SDK doesn't yet cover this call.

// check if the issue has code fix suggestions
HttpRequest requestCheckIfIssueHasCodeFix = HttpRequest.newBuilder()
    .uri(URI.create(urlFixSuggestionsIssues))
    .header("Authorization", getAuthorization())
    .build();

HttpResponse<String> response = client.send(requestCheckIfIssueHasCodeFix, BodyHandlers.ofString());
if (response.body().contains("\"aiSuggestion\":\"AVAILABLE\"")) {
  issuesWithCodeFix.add(issue);
}

Interacting with the IDE

One feature of this Dashboard is the ability to send the AI Fix to the local running instance of an IDE and commit the change to our code base.

SonarQube for IDE has an API you can use to send pieces of code that need to be refactored.

public void sendCodeFixToSonarLint(int port, Issue issue, AISuggestion issueCodeFix, String codeFile)
            throws JsonProcessingException {
        var uri = URI.create("http://localhost:" + port + SONARLINT_API_FIX +
                "?server=" + URLEncoder.encode(filter.sonarqubeUrl(), StandardCharsets.UTF_8) +
                "&project=" + filter.project() +
                "&issue=" + issueCodeFix.issueId() +
                "&branch=master");

        var codeFileLines = codeFile.split("\n");
        var sonarLintSuggestion = new SonarLintSuggestion(
                issueCodeFix.explanation(),
                new SonarLintSuggestion.FileEdit(
                        issueCodeFix.changes().stream().map(change -> new SonarLintSuggestion.FileEdit.Change(
                                change.newCode(),
                                String.join("\n",
                                        Arrays.copyOfRange(codeFileLines, change.startLine() - 1, change.endLine())),
                                new SonarLintSuggestion.FileEdit.Change.LineRange(
                                        change.startLine(),
                                        change.endLine())))
                                .toList(),
                        getFileFromComponent(issue.getComponent())),
                issueCodeFix.id());
        HttpRequest sendCodeFixToSonarLintRequest = HttpRequest.newBuilder()
                .uri(URI.create(uri.toString()))
                .POST(BodyPublishers.ofString(new ObjectMapper().writeValueAsString(sonarLintSuggestion)))
                .build();

        HttpClient client = HttpClient.newHttpClient();
        try {
            HttpResponse<String> response = client.send(sendCodeFixToSonarLintRequest, BodyHandlers.ofString());
            System.out.println(response.request().toString() + "\n" + response.body());

            writeToFileAppliedCodeFix(issueCodeFix);
            Notification.show("Response from SonarLint: " + response.statusCode() + "\n" + response.body());
        } catch (IOException | InterruptedException e) {
            e.printStackTrace();
        }
    }

Building the UI with Vaadin

Vaadin simplifies the process of building web UIs in Java by combining a component-based framework with server-side logic.

The process is to create different components and add them to layout containers.

Here’s how the project creates a dashboard page:

Vaadin Page for the dashboard

Adding the components to the layouts :

public IssuesDashboard() {
  sonarqubePanel = new HorizontalLayout();
  sonarqubeUrlEdit = new TextField("SonarQube Server URL");
  sonarqubeUrlEdit.setValue("http://localhost:9000");

  sonarqubeUserEdit = new TextField("User");
  sonarqubePasswordEdit = new TextField("Password");

  sonarqubePanel.add(sonarqubeUrlEdit, sonarqubeUserEdit, sonarqubePasswordEdit);
}

Listeners to button actions :

applyFixesButton = new Button("Send Selected Fix to SonarQube IDE");
applyFixesButton.addClickListener(e -> {
   Notification.show("Processing fixes");
   applyFixes();
   Notification.show("Processing fixes finished");
});

Bringing It All Together

To run the project:

Start the Spring Boot application:
```
./mvnw spring-boot:run
```
Access the Vaadin UI at http://localhost:8080.

You can then enter the project key, fetch issues, and explore the automation possibilities.

Conclusion

The sonarqube-bulk-ai-fix project demonstrates the power of combining the SonarQube API, Vaadin, and Spring Boot to create a user-friendly and efficient dashboard for AI code fixes. Whether you're looking to streamline your workflows or explore innovative ways to interact with SonarQube, this project provides an excellent start point.

Check out the full source code and contribute to the project on GitHub.

DEV Community: Jonathan Vila

7 habits of Highly Effective Java Coding

From AI User to AI Pro

1. The Golden Rule: Take Pride and Ownership in Your Craft 🥇

From Painful PRs to Productive Conversations

Technical Example: The AI's Brittle CompletableFuture vs. The Crafted Resilient Solution

2. Feed the Beast: Your Project's Context is its Fuel ⛽

Technical Example: The Vague Wish vs. The Detailed Brief

3. Dodge the "Ball of Mud": Keep Your Code Maintainable 🧠

Technical Example: The "Clever" Stream vs. The Debuggable Loop

4. Clean Your Room: No Stray Code or Sketchy Dependencies 🧹

Technical Example: The AI's "Helpful" but Malicious Dependency

What About Dead Code?

5. Trust but review: Analyze the AI, the Code, and the Supply Chain 🕵️‍♀️

First, Analyze Your AI System

Second, Analyze the Generated Code: Accuracy, Bugs, Security and Outdated Knowledge

The Sobering Reality of AI Accuracy

Security Vulnerabilities and Outdated Java Knowledge

Third, Analyze the Dependencies (The Software Supply Chain)

6. Beyond Coverage: Mandate Meaningful Tests ✅

AI for the Easy Stuff: Boilerplate Unit Tests

The Human's Job: Integration Tests That Build Real Confidence

The Ultimate Collaboration: AI-Powered Acceptance Tests

7. The Human Gateway: A Code Review for What AI Can't See 🧠

Focus on What Only a Human Can Judge

Example: A Conversation, Not a Judgment

Conclusion: Your AI Co-Pilot Needs a Safety Net 🚀

Building a Secure Fortress within AI: A Developer's Guide to Full-Stack Security 🏰

What we'll cover

1. Why security matters: Lessons from the real world

2. A new challenge: The age of AI-generated code 🤖

3. Securing our code: The core foundation 🕵️‍♀️

4. Securing our dependencies: The software supply chain 🌍

5. The challenge: Avoiding "Tool Sprawl" 🧩

6. A practical solution & your next step 🚀

Want to use Java 22, 23 and 24 features safely ? This article will give you tips and checks that will help you on the way.

Java 22 to 24: Level up your Java Code by embracing new features safely

Java 22 to 24: Level up your Java Code by embracing new features safely

Java 22: Unnamed variables and patterns

Rule S7466: Unnamed variable declarations should use the var identifier

Rule S7467: Unused exception parameters should use the unnamed variable pattern

Rule S7475: Types of unused record components should be removed from pattern matching

Java 23: JavaDoc and Markdown

Rule S7476: Comments should not start with more than two slashes

The compliant solution is to ensure regular comments use the standard // syntax.

Rule S7474: Markdown, HTML and Javadoc tags should not be mixed

Java 24 : Class-File API

Rule S7479: withMethodBody should be used to define methods with a body

Rule S7477: The simpler transformClass overload should be used when the class name is unchanged

Rule S7478: transformClass should be used to modify existing classes

Java 24: Stream Gatherers

Rule S7481: Sequential gatherers should use Gatherer.ofSequential

Rule S7482: Stateless gatherers should be created without a null initializer

Rule S7629: When a defaultFinisher is passed to a Gatherer factory, use the overload that does not take a finisher

Noncompliant Code Example :

Compliant Solution :

Java and SonarQube

Diving Deep into SonarQube's AI CodeFix: A Hands-On Experiment with Eclipse JKube

AI impact in the development lifecycle

What is SonarQube offering here to help?

Eclipse JKube: An Overview

Key Features and Objectives of JKube

How JKube Works

Benefits of Using JKube

AI CodeFix in Action: A Module-by-Module Breakdown

Openshift-maven-plugin

Kubernetes-maven-plugin

Gradle-plugin

Key Takeaways for Java Developers

➡️ AI gives you ✅ 𝐓𝐈𝐌𝐄 not ❌𝐂𝐎𝐍𝐅𝐈𝐃𝐄𝐍𝐂𝐄 : Developer productivity toolkit

Using AI to Understand Complex Tasks

Accelerating Code Creation

Streamlining Cloud Deployment

Creating Effective Tests

Improving Code Reviews

Increasing Code Quality and Security

Conclusion

AI Test Generation: A Dev's Guide Without Shooting Yourself in the Foot

So, AI Can Write Tests Now? Cool, But...🤔

How AI Learns to Code (And Why That's a Problem for Tests)

Technical Example: The AI's Brittle `CompletableFuture` vs. The Crafted Resilient Solution

**6. Beyond Coverage: Mandate Meaningful Tests ✅**

Rule S7466: Unnamed variable declarations should use the `var` identifier

The compliant solution is to ensure regular comments use the standard `//` syntax.

Rule S7479: `withMethodBody` should be used to define methods with a body

Rule S7477: The simpler `transformClass` overload should be used when the class name is unchanged

Rule S7478: `transformClass` should be used to modify existing classes

Rule S7481: Sequential gatherers should use `Gatherer.ofSequential`