Forem: David Nguyen

Java Varargs: What is it and how it work?

David Nguyen — Mon, 16 Dec 2024 15:35:48 +0000

1. Introducing the Problem

First, let’s answer the question: What is an arbitrary number of parameters?

It means "a flexible number of parameters." Since parameters are part of methods, the problem here is how to pass a varying number of values to a method's parameters.

Let’s look at an example below to make it clearer!

Suppose we have a sum() function used to calculate the total of the parameters passed to it. For example, we have two parameters, a and b, passed to the function like this:

public int sum(int a, int b) {
    return a + b;
}

What if we want to calculate the sum of 3 numbers, 4 numbers, or even n numbers? Before Java 5, we had two possible solutions:

Solution 1: Create an overloaded method for each possible number of parameters. For every set of parameters, you need to write a corresponding method.

public int sum(int a, int b) {
    return a + b;
}

public int sum(int a, int b, int c) {
    return a + b + c;
}

public int sum(int a, int b, int c, int d) {
    return a + b + c + d;
}

While we could use a method like sum(int a, int b, int c, int d) to calculate the sum of 2 or 3 numbers, it makes the code unclear and inefficient because of the unused parameters.

Additionally, it’s hard to predict how many numbers we might need to sum, meaning we might have to keep adding new methods as needed.

Solution 2: Pass the numbers as a list of values.

public int sum(int[] args) {
    int result = 0;
    for (int i=0; i<args.length; i++)
        result += args[i];
    return result;
}

This is probably the solution we often use for this type of problem. Naturally, it is much more flexible compared to the first solution.

=> Both solutions have their drawbacks, which is why varargs were introduced in Java 5 to address these issues. Let’s move on to the next section to see how varargs work!

2. How to use Varargs?

Varargs is just a parameter passed into a method with the syntax:

<Data Types>... <Parameter's Name>

For example, you can use varargs with the sum() function like this:

public int sum(int... args) {
    int result = 0;
    for (int i=0; i<args.length; i++)
        result += args[i];
    return result;
}

At this point, you can pass parameters into the sum() function more flexibly.

sum();             // 0
sum(1, 2);         // 3
sum(1, 2, 3);      // 6

=> Varargs solves the two problems mentioned in part 1. We no longer need to overload multiple methods or create a list beforehand.

3. How does varargs work?

The essence of varargs is arrays, or more precisely, when working with varargs, we are actually working with arrays.

You might wonder, if it's similar to arrays, what’s the difference between the method sum(int[] args) and sum(int... args)?

The answer lies in the initialization mechanism! So, how do they differ?

Case: sum(int[] args)

When using an array as a parameter, you must pass an array from outside when calling the sum() method. This means an array must be declared and initialized before the sum() method is used.

int[] params = {1, 2, 3, 4, 5};
sum(params); // 15

Case: sum(int... args)

When using varargs, instead of initializing an array beforehand, the compiler will create the array automatically when the sum() method is called. So, how does the compiler initialize it?

First, based on the number of values passed to the parameter, the compiler will create an array with a size equal to the number of values provided.

After the array is created, the compiler will assign the values we passed into that array.

In simple terms, you only need to provide the values for the parameter, and the compiler will handle the declaration and initialization for you!

sum(1, 2, 3, 4, 5); // 15

Note: It may sound convenient, but clearly, if we use varargs improperly, it could lead to performance issues. I’ll dive deeper into this in section 5.

4. What should we consider when using varargs?

4.1 - Varargs must always be the last parameter

A method that contains a varargs parameter must have that parameter as the last one. If you don't place the varargs parameter at the end, the program will throw an error.

public int sum(int initValue, int extendValue, int... args) {
    int result = initValue;
    for (int i = 0; i < args.length; i++)
        result += args[i];
    return result + extendValue;
}

sum(10, 5, 1, 2, 3); // 21

The args parameter is placed at the end, so when calling the sum() method, the values 10 and 5 are assigned to the parameters initValue and extendValue, respectively. The remaining values are passed to the args parameter.

4.2 - A method can only have one varargs parameter

If you want a method to have more than one varargs parameter, this is not possible. This actually stems from the first rule—varargs must be the last parameter.

If you have two varargs parameters, the compiler won't know which one is the last. For example, the sum() method below will immediately throw an error:

public int sum(String option, int... oddNumbers, int... evenNumbers) {   // error
    int result = 0;

    switch (option){
        case "ODD":
            for (int i = 0; i < oddNumbers.length; i++)
                result += oddNumbers[i];
            break;
        case "EVEN":
            for (int i = 0; i < evenNumbers.length; i++)
                result += evenNumbers[i];
            break;
        default:
            throw new RuntimeException("Option is not present");
    }

    return result;
}

4.3 - Avoid Ambiguity in Overloading

What is Ambiguity Overloading?

First, you probably already know what overloading is. Overloading occurs when we use methods with the same name in a class, but we need to ensure one of these three conditions:

Different number of parameters, with parameters of the same data type.
Same number of parameters, but the parameters have different data types.
Different order of data types in the parameters.

So, what is ambiguity overloading? Let’s look at the following example:

public int sum(int... args) {
    int result = 0;
    for (int i = 0; i < args.length; i++)
        result += args[i];
    return result;
}

public int sum(int initValue, int... args) {
    int result = initValue;
    for (int i = 0; i < args.length; i++)
        result += args[i];
    return result;
}

Clearly, these two methods satisfy the overloading conditions, but if I pass parameters when calling the method as shown below, it will throw an error.

=> The reason is that the value we pass makes it impossible for the compiler to distinguish whether it's the value for the initValue parameter in the method sum(int initValue, int... args) or the first value of the args parameter in the method sum(int... args).

5. How to use Varargs correctly?

5.1 - Case where one or more values are required for the parameter

A varargs parameter can accept 0 or more values. However, there are cases where we want to ensure that at least one value is passed.

For example, consider the method for finding the minimum value below:

public int min(int... args) {
    if (args.length == 0)
        throw new IllegalArgumentException("Too few arguments");
    int min = args[0];
    for (int i = 1; i < args.length; i++)
        if (args[i] < min)
            min = args[i];
    return min;
}

What’s the issue with this method?

First, when calling this method from the client, they can completely omit passing any values. Although this is checked and an exception is thrown, the problem is that this will only be known at runtime.
Second, adding such a check makes the method less clean because the logic of the method should focus solely on finding the minimum value.

How can we fix this?

It’s simple! We can add an additional parameter along with the varargs parameter to ensure that the client knows they need to pass at least one value to the method. This will also eliminate the need for runtime checks and exceptions when no values are provided.

public int min(int firstArg, int... remainingArgs) {
    int min = firstArg;
    for (int arg : remainingArgs)
        if (arg < min)
            min = arg;
    return min;
}

5.2 - Avoid overusing Varargs

Varargs gives us flexibility in passing values to parameters, but as I discussed in section 3, the essence of varargs is actually an array. And when arrays are involved, it brings concerns about memory allocation and performance.

Let’s assume that in your program, the sum() method is used around 70% of the time for summing two numbers, 20% for summing three numbers, and 10% for summing n numbers.

Should you use just one sum(int... args) method for all three cases? The answer is no, because this would affect performance. Instead of using only the sum(int... args) method, you could define all three methods like this:

public int sum(int a, int b)  {             // tính tổng hai số
    return a + b;
}

public int sum(int a, int b, int c) {       // tính tổng 3 số
    return a + b + c;
}

public int sum(int... args) {               // tính tổng n số
    int result = 0;
    for (int i = 0; i < args.length; i++)
        result += args[i];
    return result;
}

6. Conclusion

Varargs is not a new concept, as it was introduced in Java 5. However, it is still less commonly known and used by many developers. Perhaps in practice, there aren't many situations where we need to use varargs.

That said, through this article, you should now have a better understanding of when varargs is useful and how to use it correctly.

Methods like varargs aren't introduced without reason—they aim to solve a specific problem, and varargs does just that. I hope this article will help you understand varargs more clearly and apply it more effectively in your coding practices.

See you in the next posts. Happy Coding!

How To Fetch Data By Using DTO Projection In Spring Data JPA

David Nguyen — Sat, 30 Nov 2024 14:16:11 +0000

Introduction

In this post, we'll explore how projections work in Spring Data JPA, discuss different types, and walk through examples to demonstrate how they can simplify data access.

For this guide, we’re using:

IDE: IntelliJ IDEA (recommended for Spring applications) or Eclipse
Java Version: 17
Spring Data JPA Version: 2.7.x or higher (compatible with Spring Boot 3.x)
Entities Used: User (representing a user profile) and Address (representing a user’s address details)

NOTE: For more detailed examples, please visit my GitHub repository here

@Setter
@Getter
@Entity(name = "tbl_address")
public class Address {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String street;
    private String city;
    private String state;
    private String country;
    private String zipCode;
}

@Setter
@Getter
@Entity(name = "tbl_user")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String firstName;
    private String lastName;
    private String email;
    private String status;

    @OneToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "address_id", referencedColumnName = "id")
    private Address address;
}

1. Why use Projections in Spring Data JPA?

Often, your application only requires a subset of an entity's fields and loading unnecessary data can lead to:

Increased memory usage
Slow queries
Complex entity management when working with joined data

Projections come to help us avoid issues by enabling you to fetch only the data you need and in the exact format you need. This is especially useful when fetching data for RESTful APIs where not all fields of an entity are required for the response.

2. Type of Projections in Spring Data JPA.

Spring Data JPA offers several types of projections:

Interface-based Projections
Class-based Projections (DTO projection)

2.1 - Interface-based Projections

Interface-based projections allow us to define an interface with getter methods for the fields you want to retrieve. Spring Data JPA will then use these getters to map the entity's fields to the interface.

Example:

Define a projection interface and repository class:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    @Query("""
        SELECT
            concat(u.firstName, ' ', u.lastName) as fullName,
            u.email as email,
            concat( a.street, ', ', a.city, ', ', a.state) as fullAddress,
            a.country as country,
            a.zipCode as zipCode
        FROM tbl_user u
        LEFT JOIN tbl_address a ON  u.address.id = a.id
    """)
    List<UserInfoProjection> findAllUserInfo();

    interface UserInfoProjection {
        String getFullName();
        String getEmail();
        String getFullAddress();
        String getCountry();
        String getZipCode();
    }
}

Define a DTO class to transfer from projection to dto.

@Builder
@Setter
@Getter
public class UserDTO {
    private String fullName;
    private String email;
    private String address;
    private String country;
    private String zipCode;

    public static UserDTO of(UserRepository.UserInfoProjection entity) {
        if (Objects.isNull(entity))
            return null;

        return UserDTO.builder()
                .fullName(entity.getFullName())
                .email(entity.getEmail())
                .address(entity.getFullAddress())
                .country(entity.getCountry())
                .zipCode(entity.getZipCode())
                .build();
    }
}

Testing:

@SpringBootTest
@AutoConfigureMockMvc
class QueryTypesApplicationTests {
    @Autowired
    private UserRepository userRepository;

    @Test
    public void testDerivedQueryMethods() {
        List<UserDTO> results =  userRepository.findAllUserInfo()
                .stream()
                .map(UserDTO::of)
                .toList();

        assertEquals(10, results.size(), "Expected 10 users");
    }

}

2.2 - Class-based Projections

With class-based projections, we can use a custom DTO to map the results directly. This approach gives you more control over the structure of your data and can be useful if you need custom logic in the constructor.

Example:

Define DTO:

@Setter
@Getter
public class UserProjectionDTO {
    private final String fullName;
    private final String email;
    private final String address;
    private final String country;
    private final String zipCode;

    public UserProjectionDTO(String fullName, String email, String address, String country, String zipCode) {
        this.fullName = fullName;
        this.email = email;
        this.address = address;
        this.country = country;
        this.zipCode = zipCode;
    }
}

Define repository class and write sql query for getting user information.

@Repository
public interface UserRepository extends JpaRepository<User, Long> {

    @Query(
        """
            SELECT new com.davidnguyen.querytypes.user.UserProjectionDTO(
                concat(u.firstName, ' ', u.lastName),
                u.email,
                concat(a.street, ', ', a.city, ', ', a.state),
                a.country,
                a.zipCode
            )
            FROM tbl_user u LEFT JOIN tbl_address a ON u.address.id = a.id
        """
    )
    List<UserProjectionDTO> findAllUserInfo();
}

Spring Data JPA executes a query that constructs a DTO for each row of data, selecting only the fields specified in the constructor.

Testing:

@SpringBootTest
@AutoConfigureMockMvc
class QueryTypesApplicationTests {
    @Autowired
    private UserRepository userRepository;

    @Test
    public void testDerivedQueryMethods() {
        List<UserProjectionDTO> users = userRepository.findAllUserInfo();

        assertEquals(10, users.size(), "Expected 10 users");
    }

}

3. Choosing the right Projection type

Each projection type has its use case:

Interface-based projections are ideal for simple field selections.
Class-based projection are better for complex transformations or custom logic.

Performance notes:

Complex projections can lead too more complex queries, which may impact performance.
Class-based projections using DTOs my introduce overhead, especially for large result sets, because each row requires a new DTO instance. So always monitor and optimize queries as needed.

4. Best practices for DTO projections in Spring Data JPA.

Select Only the Fields You Need: Whether using class or interface-based projections, always limit the selection to only the necessary fields to optimize database load.
Use Immutability for DTOs: For class-based projections, create DTOs that are immutable (final fields, no setters) to make them safe and stable.
Consider Native Queries for Complex Joins: If your projections involve complex joins or calculated fields, consider using a native SQL query with @SqlResultSetMapping and @ConstructorResult annotations for more control.
Profile Queries for Performance: Especially with large datasets, use profiling tools (like JPA/Hibernate logging) to monitor the query performance and ensure that your projections aren’t inadvertently loading extra data.

Wrapping up

Projections in Spring Data JPA offer powerful options for controlling the data returned from the queries. By using interface-based, class-based and dynamic projections, you can fine-tune data retrieval to match you application's requirements. And keep in mind that, implementing projections effectively leads to more efficient data handling, especially in applications with large data sets.

See you in the next posts. Happy Coding!

Visit my blog for more posts.

Spring Data JPA Stream Query Methods

David Nguyen — Sun, 17 Nov 2024 06:46:35 +0000

Introduction

Traditionally, fetching large amounts of data can strain memory resources, as it often involves loading the entire result set into memory.

=> Stream query methods offer a solution by providing a way to process data incrementally using Java 8 Streams. This ensures that only a portion of the data is held in memory at any time, enhancing performance and scalability.

In this blog post, we'll dive deep into how stream query methods work in Spring Data JPA, explore their use cases, and demonstrate their implementation.

For this guide, we’re using:

IDE: IntelliJ IDEA (recommended for Spring applications) or Eclipse
Java Version: 17
Spring Data JPA Version: 2.7.x or higher (compatible with Spring Boot 3.x)

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

NOTE: For more detailed examples, please visit my GitHub repository here

1. What are Stream Query Methods?

Stream query methods in Spring Data JPA allow us to return query results as a Stream instead of a List or other collection types. This approach provides several benefits:

Efficient Resource Management: Data is processed incrementally, reducing memory overhead.
Lazy Processing: Results are fetched and processed on-demand, which is ideal for scenarios like pagination or batch processing.
Integration with Functional Programming: Streams fit with Java's functional programming features, enabling operations like filter, map, and collect.

2. How To Use Stream Query Methods?

=> Let's imagine that we are developing an e-commerce application and want to:

Retrieve all customers who placed orders after a specific date.
Filter orders with a total amount above a specific provided amount.
Group customers by their total order value within the last 6 months.
Return the data as a summary of customer names and their total order values.

Entities

Customer: Represents a customer.

@Setter
@Getter
@Entity
@Entity(name = "tbl_customer")
public class Customer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private String email;

    @OneToMany(mappedBy = "customer", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private List<Order> orders;
}

Order: Represents an order placed by a customer.

@Setter
@Getter
@Entity(name = "tbl_order")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Double amount;
    private LocalDateTime orderDate;

    @ManyToOne
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

Repository

CustomerRepository used for selecting customers and their associated orders placed after a specific date. And we used Stream<Customer> instead of List<Customer> to handle result of query.

public interface CustomerRepository extends JpaRepository<Customer, Long> {
    @Query("""
                SELECT c FROM tbl_customer c JOIN FETCH c.orders o WHERE o.orderDate >= :startDate
            """)
    @QueryHints(
            @QueryHint(name = AvailableHints.HINT_FETCH_SIZE, value = "25")
    )
    Stream<Customer> findCustomerWithOrders(@Param("startDate") LocalDateTime startDate);
}

NOTE:

The JOIN FETCH ensures orders are eagerly loaded.
The @QueryHints used to provide additional hints to the JPA provides (e.g,. Hibernate) to optimize the query execution.

=> For example, when my query return 100 records:

The first 25 records are fetched and processed by the application.
Once those are processed, the next 25 are fetched, and so on, until all 100 records are processed.
This behavior minimizes memory usage and avoids loading all 100 records into memory at once.

Service

@Service
@RequiredArgsConstructor
public class CustomerOrderService {
    private final CustomerRepository customerRepository;

    @Transactional(readOnly = true)
    public Map<String, Double> getCustomerOrderSummary(LocalDateTime startDate, Double minOrderAmount) {
        try (Stream<Customer> customerStream = customerRepository.findCustomerWithOrders(startDate)) {
            return customerStream
                    // Filter customers with orders above the threshold
                    .flatMap(customer -> customer.getOrders().stream()
                            .filter(order -> order.getAmount() >= minOrderAmount)
                            .map(order -> new AbstractMap.SimpleEntry<>(customer.getName(), order.getAmount())))
                    // Group by customer name and sum order amounts
                    .collect(Collectors.groupingBy(
                            AbstractMap.SimpleEntry::getKey,
                            Collectors.summingDouble(AbstractMap.SimpleEntry::getValue)
                    ));
        }
    }
}

Here's the service class to process the data with two parameters startDate and minOrderAmount. As you can see, we don't filter by using sql query and load all data as stream then filter and group by our Java code.

Controller

@RestController
@RequestMapping("/customers")
@RequiredArgsConstructor
public class CustomerOrderController {
    private final CustomerOrderService customerOrderService;

    @GetMapping("/orders")
    public ResponseEntity<Map<String, Double>> getCustomerOrderSummary(
            @RequestParam @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) LocalDateTime startDate,
            @RequestParam Double minOrderAmount
    ) {
        Map<String, Double> orderSummary = customerOrderService.getCustomerOrderSummary(startDate, minOrderAmount);
        return ResponseEntity.ok(orderSummary);
    }
}

Testing

=> To create data for testing, you can execute the following script inside my source code or add by yourself.

src/main/resources/dummy-data.sql

Request:

startDate: 2024-05-01T00:00:00
minOrderAmount: 100

curl --location 'http://localhost:8090/customers/orders?startDate=2024-05-01T00%3A00%3A00&minOrderAmount=100'

Response:

Return all customers with their total amount which equal or greater than minOrderAmount.

{
  "Jane Roe": 500.0,
  "John Doe": 150.0,
  "Bob Brown": 350.0,
  "Alice Smith": 520.0
}

3. Stream vs List

=> You can use IntelliJ Profiler to monitor memory usage and execution time. For more detail about how to add and test with large data set, you can find in my GitHub repository

Small Dataset: (10 customers, 100 orders)

Stream: Execution time (~5ms), Memory usage (Low)
List: Execution time (~4ms), Memory usage (Low)

Large Dataset (10.000 customers, 100.000 orders)

Stream: Execution time (~202ms), Memory usage (Moderate)
List: Execution time (~176ms), Memory usage (High)

Performance Metrics

Metric	Stream	List
Initial Fetch Time	Slightly slower (due to lazy loading)	Faster (all at once)
Memory Consumption	Low (incremental processing)	High (entire dataset in memory)
Memory Consumption	Low (incremental processing)	High (entire dataset in memory)
Processing Overhead	Efficient for large datasets	May cause memory issues for large datasets
Batch Fetching	Supported (with fetch size)	Not applicable
Error Recovery	Graceful with early termination	Limited, as data is preloaded

Wrapping up

Spring Data JPA stream query methods offer an elegant way to process large datasets efficiently while leveraging the power of Java Streams. By processing data incrementally, they reduce memory consumption and integrate seamlessly with modern functional programming paradigms.

What are your thoughts on stream query methods? Share your experiences and use cases in the comments below!

See you in the next posts. Happy Coding!