DEV Community: Victor Mithamo

Spring Boot Queries and Query Builders: A Practical Guide

Victor Mithamo — Tue, 23 Jun 2026 10:42:25 +0000

How Spring Data JPA derived methods, @Query, and query builders (Criteria API / Specifications) work, with diagrams and runnable examples.

Spring Boot doesn't run a single "query engine." Instead, it gives you several layers for talking to a database — each suited to a different level of complexity. This guide walks through how each layer works, when to reach for it, and how the type-safe query builders (Criteria API and Specifications) fit into the picture.

How a Query Travels Through a Spring Boot App

Before looking at syntax, it helps to see where queries actually live in the request lifecycle.

All query logic — no matter which technique you use — lives in the repository layer, sitting between your service code and Hibernate (the default JPA provider).

Spring Boot gives you four main ways to write a query there:

Derived query methods — Spring writes the query for you from the method name.
@Query with JPQL — you write a database-agnostic query yourself.
@Query with native SQL — you write raw SQL for the underlying database.
Query builders (Criteria API / Specification) — you build the query as Java objects at runtime.

1. Derived Query Methods

This is Spring Data JPA's signature feature: write a method signature on your repository interface, and Spring generates the SQL for you — no implementation, no annotation needed.

public interface EmployeeRepository extends JpaRepository<Employee, Long> {

    // SELECT * FROM employee WHERE last_name = ?
    List<Employee> findByLastName(String lastName);

    // SELECT * FROM employee WHERE age > ? ORDER BY last_name ASC
    List<Employee> findByAgeGreaterThanOrderByLastNameAsc(int age);

    // SELECT * FROM employee WHERE department = ? AND active = true
    List<Employee> findByDepartmentAndActiveTrue(String department);

    // SELECT COUNT(*) FROM employee WHERE department = ?
    long countByDepartment(String department);

    // SELECT * FROM employee WHERE email = ?
    Optional<Employee> findByEmail(String email);
}

How Spring parses the method name

At startup, Spring Data inspects every method on your repository interface and breaks the name apart into a subject, predicates, and modifiers.

Spring recognizes a fixed vocabulary of keywords for this parsing: And, Or, Between, LessThan, GreaterThan, Like, In, NotNull, OrderBy, True/False, IgnoreCase, and more. As long as the method name maps unambiguously to entity fields, no query implementation is required at all.

Strengths: zero boilerplate, very readable for simple lookups.
Limits: method names get unwieldy past 2–3 conditions, and there's no room for dynamic/conditional logic.

2. `@Query` with JPQL

When a derived method name would get too long, or the query needs joins, aggregation, or a SELECT of specific columns, you write JPQL (Java Persistence Query Language) — SQL that operates on entity objects and their fields rather than tables and columns.

public interface EmployeeRepository extends JpaRepository<Employee, Long> {

    @Query("SELECT e FROM Employee e WHERE e.department.name = :dept AND e.salary > :minSalary")
    List<Employee> findHighEarners(@Param("dept") String dept, @Param("minSalary") double minSalary);

    @Query("SELECT e.department.name, COUNT(e), AVG(e.salary) " +
           "FROM Employee e GROUP BY e.department.name")
    List<Object[]> getDepartmentSalaryStats();

    @Modifying
    @Transactional
    @Query("UPDATE Employee e SET e.active = false WHERE e.lastLogin < :cutoff")
    int deactivateInactiveEmployees(@Param("cutoff") LocalDate cutoff);
}

Key points:

:paramName is a named parameter, bound via @Param("paramName"). Positional parameters (?1, ?2) also work but are harder to read.
JPQL queries reference entity class and field names (Employee, e.department.name), not table or column names — this is what makes JPQL portable across databases.
@Modifying is required for UPDATE/DELETE queries; without it Spring assumes a SELECT.

3. `@Query` with Native SQL

Sometimes you need database-specific features — window functions, full-text search, vendor-specific functions — that JPQL can't express. Set nativeQuery = true and write real SQL against your actual tables.

public interface EmployeeRepository extends JpaRepository<Employee, Long> {

    @Query(value = "SELECT * FROM employee e " +
                   "WHERE e.salary > (SELECT AVG(salary) FROM employee) " +
                   "ORDER BY e.salary DESC LIMIT :limit",
           nativeQuery = true)
    List<Employee> findTopEarners(@Param("limit") int limit);
}

Native queries trade portability for power: you're now tied to your specific database's SQL dialect, but you can use anything it supports.

	Derived Methods	JPQL (`@Query`)	Native SQL (`@Query`)
Boilerplate	None	Low	Low
Complex joins/aggregation	Poor	Good	Excellent
Database portability	Full	Full	None
Dynamic/conditional filters	None	Limited	Limited
Best for	Simple lookups	Most custom queries	DB-specific features

Query Builders: Building Queries as Java Objects

The three approaches above all involve writing a query as a string — either implied by a method name or typed out as JPQL/SQL. Strings have a problem: they're checked at runtime, not compile time. A typo in a field name only surfaces when that code path executes.

Query builders solve this by letting you construct a query as a tree of Java objects, which the JPA provider then turns into SQL. The two main options in the Spring ecosystem are the JPA Criteria API (built in) and Spring Data Specifications (a friendlier wrapper around it).

Criteria API: type-safe, fully programmatic

public List<Employee> searchEmployees(String department, Double minSalary, Boolean active) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    CriteriaQuery<Employee> query = cb.createQuery(Employee.class);
    Root<Employee> employee = query.from(Employee.class);

    List<Predicate> predicates = new ArrayList<>();

    if (department != null) {
        predicates.add(cb.equal(employee.get("department"), department));
    }
    if (minSalary != null) {
        predicates.add(cb.greaterThanOrEqualTo(employee.get("salary"), minSalary));
    }
    if (active != null) {
        predicates.add(cb.equal(employee.get("active"), active));
    }

    query.where(predicates.toArray(new Predicate[0]));
    return entityManager.createQuery(query).getResultList();
}

Notice there isn't a single SQL or JPQL string anywhere — every clause is a method call. The compiler catches type mismatches (e.g., comparing a String field to an int), and the conditions are only added if the corresponding filter was actually provided. This is exactly the kind of dynamic filtering that derived methods and static @Query strings can't do.

Spring Data Specifications: Criteria API, with less ceremony

Specification<T> wraps the Criteria API in a small functional interface, and lets your repository accept composable filter objects directly.

public interface EmployeeRepository extends JpaRepository<Employee, Long>,
                                              JpaSpecificationExecutor<Employee> {
}

public class EmployeeSpecifications {

    public static Specification<Employee> hasDepartment(String department) {
        return (root, query, cb) -> department == null ? null :
            cb.equal(root.get("department"), department);
    }

    public static Specification<Employee> salaryAtLeast(Double minSalary) {
        return (root, query, cb) -> minSalary == null ? null :
            cb.greaterThanOrEqualTo(root.get("salary"), minSalary);
    }

    public static Specification<Employee> isActive() {
        return (root, query, cb) -> cb.isTrue(root.get("active"));
    }
}

// Usage in a service:
Specification<Employee> spec = Specification
        .where(EmployeeSpecifications.hasDepartment("Engineering"))
        .and(EmployeeSpecifications.salaryAtLeast(90000.0))
        .and(EmployeeSpecifications.isActive());

List<Employee> results = employeeRepository.findAll(spec);

This is the most common real-world pattern for search/filter endpoints — think an admin dashboard where the user can combine any subset of filters (department, salary range, status, hire date) and you don't want to write a separate query for every combination.

Choosing the Right Tool

Scenario	Recommended approach	Why
"Find user by email"	Derived query method	Simple, self-documenting
Report with joins/aggregates	`@Query` + JPQL	Readable, DB-portable
Vendor-specific SQL feature	`@Query` (`nativeQuery = true`)	Full SQL dialect access
Multi-filter search/dashboard	`Specification` / Criteria API	Conditions added dynamically
Bulk update/delete	`@Query` + `@Modifying`	Single round-trip to DB

Best Practices

Start with derived methods, and only move to @Query once the method name becomes hard to read (roughly 2–3 conditions is the practical ceiling).
Prefer JPQL over native SQL unless you specifically need a database feature JPQL can't express — it keeps your repository portable.
Always use named parameters (:name + @Param) over positional ones (?1) — far easier to maintain as queries grow.
Reach for Specification as soon as filters become optional/combinable — trying to do this with @Query usually means a tangle of CASE WHEN or string concatenation, which is what query builders exist to avoid.
Watch for the N+1 query problem: derived methods and JPQL fetching related entities lazily can trigger one query per row. Use JOIN FETCH in JPQL or @EntityGraph to fetch related data in a single query.
Use Pageable and Sort as method parameters on any of these approaches (findByDepartment(String dept, Pageable pageable)) instead of manually building LIMIT/OFFSET logic.

Summary

Spring Boot's query story isn't one mechanism — it's a spectrum from zero code (derived methods) to full programmatic control (Criteria API / Specifications), with @Query covering the large middle ground of custom-but-static queries. Most applications end up using all of them: derived methods for simple lookups, JPQL for reports, native SQL sparingly for special cases, and Specifications wherever users need to combine filters dynamically.

The AI Revolution: Transforming the Banking Landscape

Victor Mithamo — Fri, 19 Sep 2025 07:34:09 +0000

Artificial Intelligence (AI) is no longer a futuristic concept; it's a present-day reality rapidly reshaping industries worldwide, and banking is at the forefront of this transformation. From enhancing customer experiences to bolstering security and streamlining operations, AI offers a plethora of powerful use cases for financial institutions looking to stay competitive and efficient in the digital age.

Enhanced Customer Experience and Personalization

One of AI's most impactful contributions to banking is its ability to deliver hyper-personalized customer experiences. AI-powered chatbots and virtual assistants provide instant support, answer queries, and even help with transactions 24/7. These systems learn from customer interactions, enabling banks to offer tailored product recommendations, proactive financial advice, and customized service that significantly improves satisfaction and loyalty. Predictive analytics can even anticipate customer needs, offering relevant services before a customer even realizes they need them.

Fraud Detection and Cybersecurity

The financial sector is a prime target for fraudsters, making robust security paramount. AI excels in identifying intricate patterns and anomalies that human analysis might miss. Machine learning algorithms can process vast amounts of transaction data in real-time, flagging suspicious activities indicative of fraud. This proactive approach not only minimizes financial losses for both the bank and its customers but also strengthens the overall security infrastructure against sophisticated cyber threats.

Credit Scoring and Risk Assessment

Traditionally, credit scoring has relied on limited historical data. AI brings a new dimension to risk assessment by analyzing a broader range of data points, including non-traditional sources, to create more accurate and nuanced credit profiles. This allows banks to make more informed lending decisions, reduce default rates, and even extend credit to underserved populations previously deemed high-risk. AI models can continuously learn and adapt, improving their accuracy over time as new data becomes available.

Operational Efficiency and Automation

Mundane, repetitive tasks that consume valuable human resources can be automated using AI and Robotic Process Automation (RPA). This includes data entry, report generation, compliance checks, and customer onboarding processes. By automating these tasks, banks can significantly reduce operational costs, improve efficiency, minimize human error, and free up employees to focus on more complex, value-added activities that require critical thinking and interpersonal skills.

Algorithmic Trading and Investment Strategies

In the realm of investment banking and wealth management, AI algorithms can analyze market trends, news, and economic indicators with incredible speed and precision. This enables algorithmic trading strategies that can execute trades at optimal times, identify arbitrage opportunities, and manage portfolios more effectively. AI also assists wealth managers in providing data-driven investment advice, helping clients achieve their financial goals with greater confidence.

Regulatory Compliance and Anti-Money Laundering (AML)

Navigating the complex landscape of financial regulations is a significant challenge for banks. AI helps in automating compliance checks, monitoring transactions for potential money laundering activities, and ensuring adherence to ever-evolving regulatory requirements. AI systems can quickly identify suspicious transaction patterns that might indicate illicit financial activities, thus bolstering a bank's AML efforts and mitigating regulatory risks.

Conclusion

The integration of AI into banking is not merely an upgrade; it's a fundamental shift that promises to redefine how financial services are delivered and consumed. By leveraging AI, banks can build stronger customer relationships, fortify their defenses against fraud, optimize operational workflows, and make smarter, data-driven decisions. As technology continues to advance, the role of AI in shaping the future of banking will only grow, paving the way for a more intelligent, secure, and customer-centric financial ecosystem.

Mastering the for Loop: Strengths, Limitations, Memory Pitfalls, and Best Practices in Java and TypeScript

Victor Mithamo — Tue, 16 Sep 2025 04:22:23 +0000

Loops are fundamental in programming, allowing developers to repeat tasks without writing redundant code. Among the various loop constructs, the for loop is one of the most widely used. It offers explicit control over initialization, condition, and iteration, making it a favorite for scenarios where the number of iterations is known or predictable.

This article explores the pros and cons of for loops, along with practical examples in both Java and TypeScript.

What is a for Loop?

A for loop is a control structure that executes a block of code repeatedly until a specified condition evaluates to false.

General Syntax

// java
for (initialization; condition; update) {
    // code to execute
}

// typescript
for (initialization; condition; update) {
    // code to execute
}

Advantages of for Loops

Compact and Explicit: Initialization, condition, and iteration logic are defined in one line, making the loop structure clear.
Great for Known Iterations: Ideal when you know how many times you need to run a block of code (e.g., iterating over a fixed range).
Fine-Grained Control: Developers can manipulate the loop counter, break early, or skip iterations with break and continue.
Performance-Oriented: Traditional for loops can be slightly more performant compared to higher-level abstractions (like forEach) in performance-critical applications.

Disadvantages of for Loops

Verbosity: Compared to modern constructs like for...of in TypeScript or enhanced for in Java, traditional for loops can feel verbose.
Error-Prone: Off-by-one errors, incorrect conditions, or forgetting to update the loop variable can easily lead to bugs or infinite loops.
Readability Issues: For complex iterations, for loops may reduce readability compared to declarative approaches like streams (Java) or array methods (map, filter in TypeScript).

Practical Use Cases

Iterating Over a Range of Numbers

// java
public class RangeExample {
    public static void main(String[] args) {
        for (int i = 1; i <= 5; i++) {
            System.out.println("Number: " + i);
        }
    }
}

// typescript
for (let i = 1; i <= 5; i++) {
    console.log(`Number: ${i}`);
}

Iterating Through an Array

// java
public class ArrayExample {
    public static void main(String[] args) {
        String[] fruits = {"Apple", "Banana", "Mango"};

        for (int i = 0; i < fruits.length; i++) {
            System.out.println("Fruit: " + fruits[i]);
        }
    }
}

// typescript
const fruits: string[] = ["Apple", "Banana", "Mango"];

for (let i = 0; i < fruits.length; i++) {
    console.log(`Fruit: ${fruits[i]}`);
}

Reverse Iteration

// java
public class ReverseExample {
    public static void main(String[] args) {
        int[] numbers = {10, 20, 30, 40, 50};

        for (int i = numbers.length - 1; i >= 0; i--) {
            System.out.println("Value: " + numbers[i]);
        }
    }
}

// typescript
const numbers: number[] = [10, 20, 30, 40, 50];

for (let i = numbers.length - 1; i >= 0; i--) {
    console.log(`Value: ${numbers[i]}`);
}

Memory Issues and Complexity Considerations with for Loops

A for loop itself is lightweight — it’s just a control structure. However, how it is used can introduce memory overhead or inefficiencies.

Potential Memory Issues from for Loops

Large Data Iteration

Iterating over huge arrays or collections may load a lot of data into memory at once.
Example: looping through a 1M-element array can stress memory if each element is large (like objects).

Unnecessary Object Creation Inside Loops

Creating objects, strings, or complex data structures inside a loop repeatedly can cause heap growth and frequent garbage collection.

// java
for (int i = 0; i < 1000; i++) {
    String data = new String("Iteration " + i); // creates many unnecessary objects
}

Accumulating Results in Collections

Continuously appending to arrays, lists, or maps inside a loop without bounds can lead to out-of-memory errors.

// typescript
const results: number[] = [];
for (let i = 0; i < 1_000_000; i++) {
    results.push(i); // memory grows with each iteration
}

Infinite Loops

A bug where the loop condition never becomes false can keep allocating resources, leading to memory leaks or program crashes.

Inefficient String Concatenation

In Java, using + inside loops creates new string objects each time. Better use StringBuilder.

// java
String result = "";
for (int i = 0; i < 1000; i++) {
    result += i; // memory-heavy, creates many intermediate strings
}

Time Complexity of for Loops

The time complexity depends on the number of iterations and operations inside the loop.

Basic loop over n items:

// typescript
for (let i = 0; i < n; i++) {
    // O(1) work
}

→ Time Complexity = O(n)

Nested loops:

// java
for (int i = 0; i < n; i++) {
    for (int j = 0; j < m; j++) {
        // O(1) work
    }
}

→ Time Complexity = O(n × m)

Dependent nested loop:

// typescript
for (let i = 0; i < n; i++) {
    for (let j = 0; j < i; j++) {
        // O(1) work
    }
}

→ Time Complexity = O(n²) (triangular growth).

Space Complexity of for Loops

By themselves, for loops use constant space:

Loop counter → requires only a small fixed amount of memory (e.g., integer).
Condition and increment logic → constant memory.

So, Space Complexity = O(1) (constant) unless:

You store results in a growing collection → O(n).
You create objects per iteration → depends on number/size of objects.
Nested loops build structures → may lead to O(n²) or higher space usage.

Example Breakdown

Case 1: Just iterating

// java
for (int i = 0; i < n; i++) {
    System.out.println(i);
}

Time: O(n)
Space: O(1)

Case 2: Building a list

// typescript
const list: number[] = [];
for (let i = 0; i < n; i++) {
    list.push(i);
}

Time: O(n)
Space: O(n) (list grows with n)

Best Practices for Using for Loops in Java and TypeScript

While for loops are powerful, careless usage can cause memory inefficiencies or even performance bottlenecks. Below are best practices to help you avoid common pitfalls.

Avoid Creating Unnecessary Objects Inside Loops

Problem: Instantiating objects in every iteration leads to high memory usage and frequent garbage collection.
Better Approach: Reuse objects where possible.

// java

// ❌ Bad
for (int i = 0; i < 1000; i++) {
    String value = new String("Item " + i);
}

// ✅ Good
StringBuilder builder = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    builder.append("Item ").append(i);
}

// typescript

// ❌ Bad
for (let i = 0; i < 1000; i++) {
    const obj = { id: i, name: `Item ${i}` };
}

// ✅ Good
const template = { id: 0, name: "" };
for (let i = 0; i < 1000; i++) {
    template.id = i;
    template.name = `Item ${i}`;
    // reuse template if suitable
}

Prefer Efficient String Handling

Problem: Repeated string concatenation inside loops leads to many intermediate string objects (Java) or unnecessary copies (TypeScript).
Better Approach: Use StringBuilder (Java) or Array.join (TypeScript).

// java
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append(i).append(",");
}
System.out.println(sb.toString());

// typescript
const parts: string[] = [];
for (let i = 0; i < 1000; i++) {
    parts.push(i.toString());
}
console.log(parts.join(","));

Be Careful with Collection Growth

Problem: Continuously adding to a list or array inside a loop without bounds can cause memory spikes.
Better Approach: Pre-size collections or process data in batches.

// java

// Pre-sizing ArrayList to avoid repeated resizing
List<Integer> numbers = new ArrayList<>(1000);
for (int i = 0; i < 1000; i++) {
    numbers.add(i);
}

// typescript

// Pre-sizing array
const numbers: number[] = new Array(1000);
for (let i = 0; i < 1000; i++) {
    numbers[i] = i;
}

Prevent Infinite Loops

Problem: A missing increment or faulty condition can cause infinite loops, consuming CPU and memory.
Better Approach: Always validate loop conditions and increments.

// java

// ✅ Ensure loop progresses
for (int i = 0; i < n; i++) {
    // work
}

// typescript

// ✅ Ensure loop exits
for (let i = 0; i < n; i++) {
    // work
}

Use Alternatives When More Readable

Sometimes, modern constructs are safer and easier to understand than raw for loops.

Java (Enhanced for-loop)

// java
for (String fruit : fruits) {
    System.out.println(fruit);
}

TypeScript (for...of)

// typescript
for (const fruit of fruits) {
    console.log(fruit);
}

Conclusion

The for loop remains a cornerstone in both Java and TypeScript, providing precise control over iteration. While newer constructs (like enhanced for in Java or for...of in TypeScript) often offer cleaner and safer alternatives, the traditional for loop shines in cases requiring explicit control, reverse iteration, or performance tuning.

In modern programming, the best approach is often a balance—leveraging the for loop when control and performance matter, and preferring more readable abstractions when clarity is paramount.

For loops themselves:
- Time complexity → depends on iterations → O(n), O(n²), etc.
- Space complexity → O(1).
Memory issues come from usage patterns inside the loop:
- Unbounded collection growth.
- Repeated object creation.
- Inefficient string concatenation.
- Infinite loops.

Quick Checklist

✅ Reuse objects where possible.
✅ Use StringBuilder (Java) or join (TypeScript) for string concatenation.
✅ Pre-size collections if the size is known.
✅ Double-check loop conditions to avoid infinite loops.
✅ Use higher-level constructs (for...of, enhanced for) when readability matters.

☕ If you found this article helpful, consider supporting my work:

📬 Want to collaborate or get in touch?

🌐 Portfolio: mithamo.cc

📧 Email: hello@mithamo.cc

💻 GitHub: github.com/mithamovictor

⭐️ Check out my repositories and feel free to collaborate or reach out!

DEV Community: Victor Mithamo

Spring Boot Queries and Query Builders: A Practical Guide

How a Query Travels Through a Spring Boot App

1. Derived Query Methods

How Spring parses the method name

2. @Query with JPQL

3. @Query with Native SQL

Query Builders: Building Queries as Java Objects

Criteria API: type-safe, fully programmatic

Spring Data Specifications: Criteria API, with less ceremony

Choosing the Right Tool

Best Practices

Summary

The AI Revolution: Transforming the Banking Landscape

Enhanced Customer Experience and Personalization

Fraud Detection and Cybersecurity

Credit Scoring and Risk Assessment

Operational Efficiency and Automation

Algorithmic Trading and Investment Strategies

Regulatory Compliance and Anti-Money Laundering (AML)

Conclusion

Mastering the for Loop: Strengths, Limitations, Memory Pitfalls, and Best Practices in Java and TypeScript

What is a for Loop?

General Syntax

Advantages of for Loops

Disadvantages of for Loops

Practical Use Cases

Memory Issues and Complexity Considerations with for Loops

Potential Memory Issues from for Loops

Large Data Iteration

Unnecessary Object Creation Inside Loops

Accumulating Results in Collections

Infinite Loops

Inefficient String Concatenation

Time Complexity of for Loops

Space Complexity of for Loops

Example Breakdown

Case 1: Just iterating

Case 2: Building a list

Best Practices for Using for Loops in Java and TypeScript

Avoid Creating Unnecessary Objects Inside Loops

Prefer Efficient String Handling

Be Careful with Collection Growth

Prevent Infinite Loops

Use Alternatives When More Readable

Conclusion

Quick Checklist

☕ If you found this article helpful, consider supporting my work:

📬 Want to collaborate or get in touch?

2. `@Query` with JPQL

3. `@Query` with Native SQL