1. Introduction

The need for fast and efficient text searches often arises when developing database applications. They should also support full and partial text matches to make these searches even more user-friendly. For this purpose, MongoDB provides a couple of approaches to finding relevant documents using text searches.

In this tutorial, we’ll explore text search in MongoDB, its features, how to use it, and how to get the most out of it.

2. Text Search in MongoDB

While text search queries are a powerful tool, they require a specific setup. To achieve this, we’ll need to create a text index on the collection.

Indexes are like special folders that keep just a little bit of info from each document in a collection. In other words, they’re separate from the actual documents themselves. Moreover, MongoDB lets users make different kinds of indexes.

Fortunately, MongoDB provides text indexes designed to facilitate searches within string content. These indexes are flexible and can encompass multiple fields, allowing for comprehensive searches. Additionally, these indexes help the database search through collections much faster.

In the first place, let’s create a DB client by specifying the connection string, DB name, and collection name:

@Before
public static void setup() {
    if (mongoClient == null) {
        mongoClient = MongoClients.create("mongodb://localhost:27017");
        database = mongoClient.getDatabase("baeldung");
        collection = database.getCollection("user");
    }
}

Let’s also create a text index on the field of the collection:

void createTextIndex(String field) {
    IndexOptions indexOptions = new IndexOptions();
    indexOptions.name("textIndex").unique(false).background(true);
    collection.createIndex(Indexes.text("field"), indexOptions);
}

There’s a limitation: a collection can only have one dedicated text search index.

3. Full-Text Search

Simple full-text searches are pretty straightforward. We can input keywords or phrases, and then the system locates documents containing those exact terms.

Besides simple full-text, there are several ways to perform a full-text search. Each has its own advantages and is tailored for specific use cases. Some common ways, among others, include boolean full-text search, phrase search, and proximity search.

Let’s create a method to perform text search query:

List<Document> searchUser(String query) {
    Document result = new Document("$text", new Document("$search", name));
    return collection.find(result).into(new ArrayList<>());
}

$text performs a text search on the content of the fields indexed with a text index, whereas $search defines the target text to be searched for. Additionally, $text tokenizes the search string using whitespace and performs a logical OR of all such tokens in the search string. This means that when searching for “Java Spring”, we would find all the documents with either “Java” or “Spring” or even both.

Let’s create some records to explore full-text search functionality:

@Test
void whenSearchingUserWithFullText_thenCorrectCountReturned() {
    // WHEN
    insertUser("Leonel", "Java Spring");
    insertUser("John", "Java Spring MongoDB");
    insertUser("Smith", "Java");
    createTextIndex("description");
    // THEN
    assertEquals("All users with term 'Java' or 'Spring'", 3, searchUser("Java Spring").size());
}

We can also exclude a word by prepending a “-” character in the search query:

assertEquals("All users with term 'Java' or 'Spring' but not 'MongoDB'", 2, searchUser("Java Spring -MongoDB").size());

Similarly, we can also search for exact phrases by enclosing them in double quotes:

assertEquals("All users with term Java only", 1, searchUser("\"Java\"").size());

4. Partial Text Search

MongoDB doesn’t natively support partial searches. Unlike the full-text search, the partial, fuzzy, or substring search is not straightforward. The search feature applies the language-specific rules for stopwords and stemming.

Stemming rules for supported languages are based on standard algorithms, which address common verbs and nouns and are often unaware of proper nouns. 

Let’s try to search for a user with a partial search:

@Test
void whenSearchingUserWithPartialText_thenCorrectCountReturned() {
    // WHEN
    insertUser("LEONEL", "Java Spring");
    createTextIndex("name");
    // THEN
    assertEquals("Search with capital case", 1, mongoDBClient.searchUser("LEONEL").size());
    assertEquals("Search with lower case", 1, mongoDBClient.searchUser("leonel").size());
    assertEquals("Partial search", 1, mongoDBClient.searchUser("LEONE").size());
}

On the contrary, the system cannot locate ‘L’, ‘LEO’, or ‘NEL’ due to the stemming rules:

assertEquals("Partial search with L", 0, searchUser("L").size());
assertEquals("Partial search with LEO", 0, searchUser("LEO").size());
assertEquals("Partial search with NEL", 0, searchUser("NEL").size());

One of the workaround for the partial search is to use $regex. For this cause, we will not need the text index, which may slow the search operation if the collection is very large. 

5. Conclusion

In this quick tutorial, we’ve examined full and partial text searches in MongoDB. We learned about using search queries to find exactly what we are looking for and to exclude certain terms from our search results. We also discovered that prefix and postfix do not match in a document for partial searches and identified a workaround.

As always, all the code snippets can be found over on GitHub.

       

1. Overview

Optimizing code for performance is a key part of programming, especially when dealing with expensive operations or data retrieval processes.  One effective way of improving performance is caching.

The Project Reactor library provides a cache() method to cache expensive operations or data that hardly changes to avoid repeat operations and improve performance.

In this tutorial, we’ll explore memoization, a form of caching, and demonstrate how to use Mono.cache() from the Project Reactor library to cache the results of the HTTP GET request to JSONPlaceholder API. Also, we’ll understand the internals of Mono.cache() method through a marble diagram.

2. Understanding Memoization

Memoization is a form of cache that stores the output of expensive function calls. Then, it returns the cached result when the same function call occurs again.

It’s useful in a case involving recursive functions or computations that always produce the same output for a given input.

Let’s see an example that demonstrates memoization in Java using the Fibonacci sequence. First, let’s create a Map object to store the cache the result:

private static final Map<Integer, Long> cache = new HashMap<>();

Next, let’s define a method to compute the Fibonacci sequence:

long fibonacci(int n) {
    if (n <= 1) {
        return n;
    }
    if (cache.containsKey(n)) {
        return cache.get(n);
    }
    long result = fibonacci(n - 1) + fibonacci(n - 2);
    logger.info("First occurrence of " + n);
    cache.put(n, result);
    return result;
}

In the code above, we check if the integer n is already stored in the Map object before further computation. If it’s already stored in the Map object, we return the cached value. Otherwise, we compute the result recursively and store it in the Map object for future use.

This method significantly improves the performance of the Fibonacci calculation by avoiding redundant computations.

Let’s write a unit test for the method:

@Test
void givenFibonacciNumber_whenFirstOccurenceIsCache_thenReturnCacheResultOnSecondCall() {
    assertEquals(5, FibonacciMemoization.fibonacci(5));
    assertEquals(2, FibonacciMemoization.fibonacci(3));
    assertEquals(55, FibonacciMemoization.fibonacci(10));
    assertEquals(21, FibonacciMemoization.fibonacci(8));
}

In the test above, we invoke the fibonacci() to compute sequences.

3. Describing Mono.cache() with Marble Diagram

The Mono.cache() operator helps cache the result of a Mono publisher and return the cached value for subsequent subscriptions.

The marble diagram helps to understand the internal details of reactive classes and how they work. Here’s a marble diagram that illustrates the behavior of the cache() operator:

In the image above, the first subscription to the Mono publisher emits data and caches it. Subsequent subscriptions retrieve the cached data without triggering a new computation or data fetch.

4. Example Setup

To demonstrate the usage of Mono.cache(), let’s add reactor-core to the pom.xml:

<dependency>
    <groupId>io.projectreactor</groupId>
    <artifactId>reactor-core</artifactId>
    <version>3.6.5</version>
</dependency>

The library provides operators, Mono, Flux, etc., to implement reactive programming in Java.

Also, let’s add spring-boot-starter-webflux to the pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
    <version>3.2.5</version>
</dependency>

The above dependency provides the WebClient class to consume an API.

Also, let’s see a sample response when we get a GET request to https://jsonplaceholder.typicode.com/users/2:

{
    "id": 2,
    "name": "Ervin Howell",
    "username": "Antonette"
    // ...
}

Next, let’s create a POJO class named User to deserialize the JSON response from the GET request:

public class User {
    private int id;
    private String name;
    // standard constructor, getter and setter
}

Furthermore, let’s create a WebClient object and set the base URL for the API:

WebClient client = WebClient.create("https://jsonplaceholder.typicode.com/users");

This serves as the base URL for the HTTP response that will be cached using the cache() method.

Finally, let’s create an AtomicInteger object:

AtomicInteger counter = new AtomicInteger(0);

The object above helps to keep track of the number of times we make a GET request to the API.

5. Fetching Data Without Memoization

Let’s start by defining a method that fetches a user from the WebClient object:

Mono<User> retrieveOneUser(int id) {
    return client.get()
      .uri("/{id}", id)
      .retrieve()
      .bodyToMono(User.class)
      .doOnSubscribe(i -> counter.incrementAndGet())
      .onErrorResume(Mono::error);
}

In the code above, we retrieve a user with a specific ID and map the response body to a User object. Also, we increment the counter on every subscription.

Here’s a test case that demonstrates fetching a user without caching:

@Test
void givenRetrievedUser_whenTheCallToRemoteIsNotCache_thenReturnInvocationCountAndCompareResult() {
    MemoizationWithMonoCache memoizationWithMonoCache = new MemoizationWithMonoCache();
    Mono<User> retrieveOneUser = MemoizationWithMonoCache.retrieveOneUser(1);
    AtomicReference<User> firstUser = new AtomicReference<>();
    AtomicReference<User> secondUser = new AtomicReference<>();
    Disposable firstUserCall = retrieveOneUser.map(user -> { 
          firstUser.set(user);
          return user.getName();
      })
      .subscribe();
    Disposable secondUserCall = retrieveOneUser.map(user -> { 
          secondUser.set(user);
          return user.getName();
      })
      .subscribe();
    assertEquals(2, memoizationWithMonoCache.getCounter());
    assertEquals(firstUser.get(), secondUser.get());
}

Here, we subscribe to the retrieveOneUser Mono twice, and each subscription triggers a separate GET request to the WebClient object. We assert that the counter increments twice.

6. Fetching Data With Memoization

Now, let’s modify the previous example to leverage Mono.cache() and cache the result of the first GET request:

@Test
void givenRetrievedUser_whenTheCallToRemoteIsCache_thenReturnInvocationCountAndCompareResult() {
    MemoizationWithMonoCache memoizationWithMonoCache = new MemoizationWithMonoCache();
    Mono<User> retrieveOneUser = MemoizationWithMonoCache.retrieveOneUser(1).cache();
    AtomicReference<User> firstUser = new AtomicReference<>();
    AtomicReference<User> secondUser = new AtomicReference<>();
    Disposable firstUserCall = retrieveOneUser.map(user -> {
          firstUser.set(user);
          return user.getName();
      })
      .subscribe();
    Disposable secondUserCall = retrieveOneUser.map(user -> {
          secondUser.set(user);
          return user.getName();
      })
      .subscribe();
    assertEquals(1, memoizationWithMonoCache.getCounter());
    assertEquals(firstUser.get(), secondUser.get());
}

The major difference from the previous example is that we invoke the cache() operator on the retrieveOneUser object before subscribing to it. This caches the result of the first GET request, and subsequent subscriptions receive the cached result instead of triggering a new request.

In the test case, we assert that the counter increment once since the second subscription uses the cached value.

7. Setting a Cache Duration

By default, Mono.Cache() caches the result indefinitely. However, in a scenario where the data could become stale over time, it’s essential to set a cache duration:

// ... 
Mono<User> retrieveOneUser = memoizationWithMonoCache.retrieveOneUser(1)
  .cache(Duration.ofMinutes(5));
// ...

In the code above, the cache() method accepts an instance of Duration as a parameter. The cached value will expire after 5 minutes, any subsequent subscriptions after will trigger a new GET request.

8. Conclusion

In this article, we learned the key concept of memorization and its implementation in Java using the Fibonacci sequence example. Then, we deep dive into the usage of Mono.cache() from the Project Reactor library and demonstrate how to cache the results of HTTP GET requests.

Caching is a powerful technique for improving performance. However, it’s essential to consider cache invalidation strategies to ensure that stale data is not served indefinitely.

As always, the complete source code for the example is available over on GitHub.

       

1. Introduction

Java introduced the Optional class in Java 8 to represent a value that may or may not be present. It helps us to avoid NullPointerException and write more expressive and readable code. Converting an Optional to an ArrayList can be useful in scenarios where we want to handle optional values as lists. In this tutorial, we’ll explore different approaches to convert an Optional to an ArrayList in Java.

2. Using isPresent()

This approach leverages the isPresent() method provided by the Optional class to handle a value’s presence or absence. It’s particularly useful when we want to explicitly check if the Optional contains a value before performing certain actions or applying custom logic.

Let’s see a code snippet that uses the isPresent() method:

Optional<String> optionalValue = Optional.of("Hello, World!");
List<String> arrayList = new ArrayList<>();
if (obj.isPresent()) {
    arrayList.add(obj.get());
}
assertTrue(arrayList.contains("Hello, World!"));

We begin by creating an Optional object named optionalValue, containing the value “Hello, World!”. This value is encapsulated within the Optional, signifying its potential absence. Subsequently, we employ the ifPresent() method provided by the Optional class.

If the value is present within the Optional, we retrieve the value using the get() method and add it to the ArrayList.

3. Using orElse() or orElseGet()

This approach leverages the orElse() method provided by the Optional class. It allows us to specify a default value to use if the Optional is empty. This is particularly useful when we have a fallback value or behavior we want to apply when the Optional doesn’t contain a value.

In this case, we’re creating an empty Optional, so when the orElse() method is invoked, it will return a default value of “Hello World”:

Optional<String> emptyOptional = Optional.empty();
List<String> arrayList = new ArrayList<>();
arrayList.add(emptyOptional.orElse("Hello World!"));
assertTrue(arrayList.contains("Hello, World!"));

In the example, we create an empty Optional named emptyOptional using the empty() method. Since the emptyOptional is empty, calling orElse() will return the specified default value, “Hello World”. Then, we add this default value to the ArrayList.

Note that when using orElse(), the provided default value is evaluated eagerly. This means it’s calculated regardless of whether the Optional needs it. Even if the Optional holds a non-null value, the default value is still created, whereas the default value provided to orElseGet() is evaluated lazily. It’s only invoked if the Optional is empty.

Moreover, for performance-critical scenarios, orElseGet() is usually preferred because it avoids unnecessary computation when the Optional already contains a value:

Optional<String> emptyOptional = Optional.empty(); 
List<String> arrayList = new ArrayList<>(); 
arrayList.add(emptyOptional.orElseGet(() -> "Hello, World!")); 
assertTrue(arrayList.contains("Hello, World!"));

4. Using Java Streams

A Stream in Java represents a sequence of elements that can be processed in a pipeline of operations. We can utilize the Streams API to create the ArrayList conditionally.

4.1. Implementation

Let’s look at an example using Java Streams to convert an Optional object to ArrayList:

Optional<String> optionalValue = Optional.of("Hello, World!");
List<String> arrayList = optionalValue
  .stream()
  .collect(Collectors.toList());
assertTrue(arrayList.contains("Hello, World!"));

First, we create an Optional object named optionalValue with a value of “Hello, World!”. Next, we convert the Optional to an ArrayList using a Java Stream. We call the stream() method on optionalValue to obtain a stream of its elements. Then, we use the collect() method with Collectors.toList() to collect the elements of the stream into a List, effectively converting the Optional to an ArrayList.

If the Optional is empty, meaning it does not contain a value, the resulting ArrayList will also be empty. In Java Streams, if the stream source is empty, the terminal operation — collect() in this case — will simply return an empty collection.

4.2. Stream Filtering

One of the advantages of using Java Stream API is that it allows us to process elements conditionally and perform various transformations. Imagine we only want to add values to the ArrayList if they meet certain criteria. Streams allow us to incorporate filter() before collecting elements into a list:

Optional<String> optionalValue = Optional.of("Hello, World!");
List<String> arrayList = optionalValue
  .filter(e -> e.startsWith("H"))
  .stream()
  .collect(Collectors.toList());
assertTrue(arrayList.contains("Hello, World!"));

Here, we filter the Optional containing a list of String using filter(). This method keeps only elements that start with the letter “H”. We then collect the resulting filtered elements into an ArrayList using the collect(Collectors.toList()) method.

4.3. Stream Flattening

Java Streams offer an additional advantage when dealing with nested lists. Consider a scenario where an Optional contains another Optional, which in turn holds a list. We can use Java Streams to flatten the nested list.

Let’s write an example that demonstrates how to flatten a nested list within an Optional:

Optional<List<String>> optionalList = Optional.of(Arrays.asList("Apple", "Banana", "Cherry"));
List<String> arrayList = optionalList
  .stream()
  .flatMap(List::stream)
  .collect(Collectors.toList());
assertEquals(3, arrayList.size());
assertTrue(arrayList.contains("Apple"));

We call stream() on the Optional<List<String>> to convert it into a stream. Next, we use flatMap(List::stream). This applies the List::stream method reference to each element in the stream. By applying flatMap(), we essentially “flatten” the nested structure. Instead of a single stream containing a list, we now have a stream containing the individual elements from the inner list.

5. Conclusion

In this article, we explored various approaches to convert Optional to ArrayList. We use the isPresent() method if we need to perform specific actions based on the presence of an Optional value. When we have a default value to use if the Optional is empty, we can use orElse() or orElseGet(). Lastly, Java Streams is a good option for concise conversions, especially if we need to do filtering before converting to a list.

As always, the source code for the examples is available over on GitHub.

       

1. Introduction

In Java programming, dealing with collections is a fundamental task. Lists and Maps are two commonly used collection types, and sometimes, we might need to work with a List of Maps. Whether we’re processing data, manipulating configurations, or any other task that involves complex data structures, efficiently iterating through a List of Maps is crucial.

In this tutorial, we’ll explore various techniques for iterating through a List of Maps in Java.

2. Understanding List of Maps

Before we explore iteration techniques, let’s grasp the concept of a List of Maps.

A List of Maps comprises multiple Map objects, each capable of holding key-value pairs where the keys remain unique within each Map. This structure offers remarkable versatility and finds common applications in representing tabular data, configurations, or any other data requiring key-to-value mappings.

Let’s consider a List of Maps:

List<Map<String, Object>> listOfMaps = new ArrayList<>();
Map<String, Object> map1 = new HashMap<>();
map1.put("name", "Jack");
map1.put("age", 30);
listOfMaps.add(map1);
Map<String, Object> map2 = new HashMap<>();
map2.put("name", "Jones");
map2.put("age", 25);
listOfMaps.add(map2);

3. Iterating a List of Maps Using Traditional Loops

One of the most straightforward approaches to iterating through a List of Maps is using traditional loops, such as for loops:

for (Map<String, Object> map : listOfMaps) {
    for (Map.Entry<String, Object> entry : map.entrySet()) {
        String key = entry.getKey();
        Object value = entry.getValue();
        System.out.format("%s: %s\n", key, value);
    }
}

We first iterate over the List in this approach, obtaining each Map. Then, for each Map, we iterate over its entries using entrySet(), allowing us to access the key and value of each entry.

Here’s the output:

name: Jack
age: 30
name: Jones
age: 25

3.1. Iterating Using Map.keySet() and Map.get()

Alternatively, we can use the keySet() method of the Map interface to retrieve a Set that contains all the keys in the Map. We can then iterate through this Set, and for each key, fetch the corresponding value using the get() method:

for (Map<String, Object> map : listOfMaps) {
    for (String key : map.keySet()) {
        Object value = map.get(key);
        System.out.format("%s: %s\n", key, value);
     }
}

4. Iterating Using Java Stream

Java 8 introduced streams, providing a more functional approach to processing collections. We can leverage streams to iterate through a List of Maps:

listOfMaps.stream()
  .flatMap(map -> map.entrySet().stream())
  .forEach(entry -> {
      String key = entry.getKey();
      Object value = entry.getValue();
      System.out.format("%s: %s\n", key, value);
  });

Here, we use the flatMap() operation to transform each Map into a stream of its entries. Then, we iterate over each entry and process it accordingly.

5. Iterating Using forEach() Loop With Lambda Expressions

We can iterate through a List of Maps using a forEach() loop combined with lambda expressions:

listOfMaps.forEach(map -> {
    map.forEach((key, value) -> {
        System.out.println("%s: %s\n", key, value);
    });
});

6. Conclusion

In this article, we saw that iterating through a List of Maps in Java can be done in various ways. By mastering the techniques discussed, we’ll be better equipped to handle complex data structures effectively. Whether we prefer traditional loops or streams, choosing the right approach depends on the specific requirements of our project and our coding style preferences.

The source code of all these examples is available over on GitHub.

       

1. Overview

In this tutorial, we’ll explore different methods of converting Jackson’s raw data type JsonNode into typed Java collections. While we can read JSON using JsonNode itself, converting it to a Java collection can be beneficial. Java collections provide advantages over raw JSON data such as type safety, faster processing, and availability of more type-specific operations.

2. Example Setup

In our code example, we’ll look at different ways to convert a JsonNode to a List or Map of objects. Let’s set up the building blocks of our example.

2.1. Dependency

To start with, let’s add the Jackson Core dependency to the pom.xml file:

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.17.0</version>
</dependency>

2.2. JSON Data

Next, let’s define a JSON for our use case:

{
    "persons": [
        {
            "name": "John",
            "age": 30
        },
        {
            "name": "Alice",
            "age": 25
        }
    ],
    "idToPerson" : {
        "1234": {
            "name": "John",
            "age": 30
        },
        "1235": {
            "name": "Alice",
            "age": 25
        }
    }
}

In the above JSON, we have a JSON array persons and a JSON object idToPerson. We’ll look at methods to convert them to Java collections.

2.3. The DTO

Let’s define a Person class that we can use in our example:

public class Person {
    private String name;
    private int age;
    
    // constructors/getters/setters
}

2.4. Converting JSON String to JsonNode

If we want to read an object from the entire JSON, we can use the ObjectMapper class of Jackson to do so:

JsonNode rootNode = new ObjectMapper().readTree(jsonString);
JsonNode childNode = rootNode.get("persons");

To convert the entire JSON into a JsonNode object, we use the readTree() method. We then traverse the JsonNode object using the get() method that returns the nested object with the specified name.

3. Manual Conversion

Before checking library methods, let’s look at a way to convert a JsonNode into a collection manually.

3.1. Manually Converting JsonNode to List

To convert a JsonNode to a list, we can traverse it entry by entry and create a List object with it:

List<Person> manualJsonNodeToList(JsonNode personsNode) {
    List<Person> people = new ArrayList<>();
    for (JsonNode node : personsNode) {
        Person person = new Person(node.get("name").asText(), node.get("age").asInt());
        people.add(person);
    }
    return people;
}

Here, we use a loop to traverse all children of the input node. This is possible only if our input node is an array.

For each node, we create a Person object and add it to the list. We get name and age from the node using the get(fieldName) method. JsonNode provides various methods to convert the returned value into primitive Java types. Here, the asText() and asInt() methods convert the value to String and int, respectively.

3.2. Manually Converting JsonNode to Map

Let’s look at a similar conversion for the map:

Map<String, Person> manualJsonNodeToMap(JsonNode idToPersonsNode) {
    Map<String, Person> mapOfIdToPerson = new HashMap<>();
    idToPersonsNode.fields()
      .forEachRemaining(node -> mapOfIdToPerson.put(node.getKey(),
        new Person(node.getValue().get("name").asText(), node.getValue().get("age").asInt())));
    return mapOfIdToPerson;
}

Here, we use the fields() method to iterate over map entries. It returns an Iterator<Map.Entry<String, JsonNode>> object that we can process further. Next, we read each entry and put it into our Map.

4. Using Jackson’s readValue() and convertValue()

Jackson provides multiple methods to convert JsonNode into Java objects. Let’s look at two of them.

4.1. Using readValue()

The readValue() method can be used to convert to List or Map using a TypeReference:

List<Person> readValueJsonNodeToList(JsonNode personsNode) throws IOException {
    TypeReference<List<Person>> typeReferenceList = new TypeReference<List<Person>>() {};
    return new ObjectMapper().readValue(personsNode.traverse(), typeReferenceList);
}
Map<String, Person> readValueJsonNodeToMap(JsonNode idToPersonsNode) throws IOException {
    TypeReference<Map<String, Person>> typeReferenceMap = new TypeReference<Map<String, Person>>() {};
    return new ObjectMapper().readValue(idToPersonsNode.traverse(), typeReferenceMap);
}

First, we create a TypeReference object by passing the exact type we need to convert to. We then call the readValue() method where JsonParser is provided by jsonNode.traverse(). Using the parser, it deserializes the node to a list or map as per the TypeReference we provide.

4.2. Using convertValue()

Similarly, we can use the convertValue() method:

List<Person> convertValueJsonNodeToList(JsonNode personsNode) {
    TypeReference<List<Person>> typeReferenceList = new TypeReference<List<Person>>() {};
    return new ObjectMapper().convertValue(personsNode, typeReferenceList);
}
Map<String, Person> convertValueJsonNodeToMap(JsonNode idToPersonsNode) {
    TypeReference<Map<String, Person>> typeReferenceMap = new TypeReference<Map<String, Person>>() {};
    return new ObjectMapper().convertValue(idToPersonsNode, typeReferenceMap);
}

The convertValue() method works by first serializing the input object and then deserializing it to the desired type. Therefore, it can be used more flexibly for converting from one object to another. For example, we could also use it for reverse comparison from a Java object to JsonNode.

5. Custom Deserializer

We can also provide a custom deserializer to perform the conversion. Let’s look at how we can define one:

public class CustomPersonListDeserializer extends JsonDeserializer<List<Person>> {
    @Override
    public List<Person> deserialize(com.fasterxml.jackson.core.JsonParser p, 
      com.fasterxml.jackson.databind.DeserializationContext ctxt) throws IOException {
        ObjectMapper objectMapper = (ObjectMapper) p.getCodec();
        List<Person> personList = new ArrayList<>();
        JsonNode personsNode = objectMapper.readTree(p);
        for (JsonNode node : personsNode) {
            personList.add(objectMapper.readValue(node.traverse(), Person.class));
        }
        return personList;
    }
}

Let’s look at a few important parts of the code:

• First, the class extends Jackson’s JsonDeserializer.
• Then, we override the deserialize() method and provide our implementation.
• In the implementation, we get the ObjectMapper from the JsonParser object.
• objectMapper.readTree() converts the entire tree represented by the parser into a JsonNode instance.
• Finally, similar to the manual conversion, we convert each node in the JSON array to a Person object by looping over the nodes.

The deserializer works similarly to other methods, except it can provide a separation of concern. Additionally, custom deserializers provide flexibility as we can easily switch between deserializers in the calling code.

We’ll look at how to use the deserializer when we test the code in the next section.

6. Testing

Now that we have our different methods ready, let’s write some tests to verify them.

6.1. Setup

Let’s set up our test class:

public class JsonNodeToCollectionUnitTest {
    public static String jsonString = "{\"persons\":[{\"name\":\"John\",\"age\":30},{\"name\":\"Alice\",\"age\":25}],\"idToPerson\":{\"1234\":{\"name\":\"John\",\"age\":30},\"1235\":{\"name\":\"Alice\",\"age\":25}}}";
    static JsonNode completeJson;
    static JsonNode personsNode;
    static JsonNode idToPersonNode;
    @BeforeAll
    static void setup() throws JsonProcessingException {
        completeJson = new ObjectMapper().readTree(jsonString);
        personsNode = completeJson.get("persons");
        idToPersonNode = completeJson.get("idToPerson");
    }
}

Here, we define a JSON string that we can use as a test input. Then, we define a setup() method that executes before all tests. It sets up our input JsonNode objects.

6.2. Testing Conversion Methods

Next, let’s test our conversion methods:

@Test
void givenJsonNode_whenConvertingToList_thenFieldsAreCorrect() throws IOException {
    List<Person> personList1 = JsonNodeConversionUtil.manualJsonNodeToList(personsNode);
    List<Person> personList2 = JsonNodeConversionUtil.readValueJsonNodeToList(personsNode);
    List<Person> personList3 = JsonNodeConversionUtil.convertValueJsonNodeToList(personsNode);
    validateList(personList1);
    validateList(personList2);
    validateList(personList3);
}
private void validateList(List<Person> personList) {
    assertEquals(2, personList.size());
    Person person1 = personList.get(0);
    assertEquals("John", person1.getName());
    assertEquals(30, person1.getAge());
    Person person2 = personList.get(1);
    assertEquals("Alice", person2.getName());
    assertEquals(25, person2.getAge());
}

Here, we call each method and verify that the contents of the returned list are as we expected.

Let’s add a similar test for map conversions:

@Test
void givenJsonNode_whenConvertingToMap_thenFieldsAreCorrect() throws IOException {
    Map<String, Person> personMap1 = JsonNodeConversionUtil.manualJsonNodeToMap(idToPersonNode);
    Map<String, Person> personMap2 = JsonNodeConversionUtil.readValueJsonNodeToMap(idToPersonNode);
    Map<String, Person> personMap3 = JsonNodeConversionUtil.convertValueJsonNodeToMap(idToPersonNode);
    validateMapOfPersons(personMap1);
    validateMapOfPersons(personMap2);
    validateMapOfPersons(personMap3);
}
private void validateMapOfPersons(Map<String, Person> map) {
    assertEquals(2, map.size());
    Person person1 = map.get("1234");
    assertEquals("John", person1.getName());
    assertEquals(30, person1.getAge());
    Person person2 = map.get("1235");
    assertEquals("Alice", person2.getName());
    assertEquals(25, person2.getAge());
}

6.3. Testing Custom Deserializer

Let’s see how to use the custom deserializer and then compare the results:

@Test
void givenJsonNode_whenConvertingToListWithCustomDeserializer_thenFieldsAreCorrect() throws IOException {
    ObjectMapper objectMapper = new ObjectMapper();
    SimpleModule module = new SimpleModule();
    module.addDeserializer(List.class, new CustomPersonListDeserializer());
    objectMapper.registerModule(module);
    List<Person> personList = objectMapper.convertValue(personsNode, new TypeReference<List<Person>>() {
    });
    validateList(personList);
}

Here, we first wrap the CustomPersonListDeserializer in a module using the SimpleModule class. Then, we register this module with the ObjectMapper instance. By doing this, we instruct the ObjectMapper to use CustomPersonListDeserializer whenever a List needs to be deserialized.

When we call the convertValue() method next, the deserializer is used to return the output list.

7. Conclusion

In this article, we explored how to convert Jackson’s JsonNode into typed Java collections like List and Map. We discussed multiple methods to perform this operation and tested that they all provide the same output.

For small conversions, we may use the manual method. As the JSON size grows, using methods from Jackson’s library would be better. And if a more complex conversion is required, it would be better to provide our custom deserializer.

As usual, the source code for the examples can be found over on GitHub.

       

1. Overview

In this tutorial, we’ll learn how to convert a Queue object into a List in Java.

We’ll explain several popular ways of doing this along with their implementations, and we’ll end each section with a test case to test the respective implementation.

2. Ways to Convert Queue to List

In this section, we’ll cover different ways to convert the Queue to a List using standard Java classes and methods. We’re assuming a non-null queue for all examples.

2.1. Using the ArrayList Constructor

The ArrayList constructor provides the easiest and most common way to convert a Queue to an ArrayList.

The idea is to pass the Queue as a parameter to the ArrayList constructor:

List<String> list = new ArrayList<>(queue);

The constructor new ArrayList<>(queue) efficiently inserts all of the queue elements into the new ArrayList.

2.2. Using the addAll() method

The addAll() method is another great option to consider if we want to convert a Queue to a List.

As the name implies, this method allows adding all elements in the specified collection to the List.

Now, let’s see the logic:

List<String> list = new ArrayList<>();
list.addAll(queue);

We create a new List named list and populate it with the elements of the queue using the addAll() method. The method then returns the resultant list.

2.3. Using the LinkedList Constructor

The LinkedList constructor provides the most common and easiest way to convert a Queue to a LinkedList.

Similar to the above example using the ArrayList constructor, we simply pass the Queue as a parameter to the LinkedList constructor:

LinkedList<String> list = new LinkedList<>(queue);

The constructor new LinkedList<>(queue) efficiently converts the queue elements into the new LinkedList.

2.4. Using Stream API

Java 8 comes with a lot of new features that help in enhancing our code. Among these features, we find the Stream API.

Let’s illustrate how to use the stream API to convert a Queue to a List:

List<String> list = queue.stream().collect(Collectors.toList());

We convert the queue to a List using the collect(Collectors.toList()) operation, which collects the elements of the stream into a new list and returns it. This approach leverages a concise and functional programming style with streams to perform the conversion.

2.5. Using Guava

Guava is a popular open-source library developed by Google that provides a wide range of utility classes and methods to simplify common programming tasks in Java.

Let’s use Guava to convert Queue to List:

List<String> list = Lists.newArrayList(queue);

Guava’s utility method Lists.newArrayList(queue) simplifies the process of creating a new list from the elements of a queue.

3. Conclusion

In this article, we saw various ways to convert Queue to List in Java. Whether we prefer the simplicity of LinkedList, the versatility of ArrayList, the elegance of Java 8 streams, or the power of Guava, understanding these techniques empowers us to handle data seamlessly in our Java projects. We can experiment with these approaches to find the one best suited to our requirements and coding style.

The source code of all these examples is available over on GitHub.

       

1. Spring and Java

>> This is not your uncle’s Java! Modelling with Java 22 records pattern matching in practice [event-driven.io]

Java has come a long way, but it was definitely worth the wait!

>> Explicit vs Diagnostic GC [javaspecialists.eu]

Don’t help your garbage collector! It’s doing fine on its own

>> Let’s Replace the synchronized Keyword [foojay.io]

The synchronized keyword can be a problem in the world of Virtual Threads, but luckily trivial alternatives do exist.

Also worth reading:

• >> JEP 474: Generational Mode Now Standard for ZGC in Java [infoq.com]
• >> JetBrains IntelliJ IDEA 2024.1 Delivers Support for Java 22 Features [infoq.com]
• >> Writing a Data Orchestrator in Java [foojay.io]
• >> JEP targeted to JDK 23: 474: ZGC: Generational Mode by Default [openjdk.org]
• >> Publisher-Subscriber Pattern Using AWS SNS and SQS in Spring Boot [reflectoring.io]
• >> JEP 476: Module Import Declarations (Preview) [openjdk.org]
• >> The Devoxx Genie IntelliJ Plugin Provides Access to Local or Cloud Based LLM Models [infoq.com]
• >> Advanced Practices in Spring Boot: Building a Modular Application with Docker, Zipkin, and 100% Code Coverage [makariev.com]

Webinars and presentations:

• >> Spring Tips: Spring Cloud Gateway for Spring MVC [spring.io]
• >> Spring Tips: Beans, Beans: What’s in a Spring bean? [spring.io]
• >> Java Withers – Inside Java Newscast #67 [inside.java]
• >> JavaDoc Hits the Markdown on Comments – Inside Java Newscast #68 [inside.java]
• >> A Simple Plain-Text Knowledge System [sebastian-daschner.com]
• >> A Bootiful Podcast: Carl Azoury, Zenika founder and CEO [spring.io]
• >> Foojay Podcast #48: JUG Oberpfalz, JCON Conference, and JAVAPRO Magazine [foojay.io]
• >> Spring Tips: Vector Databases with Spring AI [spring.io]

Time to upgrade:

• >> Spring Functions Catalog 5.0.0‐RC1 & Spring Cloud Stream Applications 2024.0.0-RC1 Available [spring.io]
• >> Spring Tools 4.22.1 released [spring.io]
• >> Hibernate 7.0.0.Alpha2 [in.relation.to]
• >> Infinispan Unveils 15.0.0 with an Advanced RESP Endpoint and Requires JDK 17 [infoq.com]
• >> JobRunr Introduces Version 7.0 with Builtin Support for Virtual Threads [infoq.com]

2. Technical & Musings

>> The Vary HTTP header [frankel.ch]

Did you know about Vary HTTP header? I certainly did not

Also worth reading:

• >> Five ways to pass parameters to Apache APISIX [foojay.io]
• >> Notes on setting up vm-bhyve [skife.org]
• >> Knowledge Graphs – What Are They? [scottlogic.com]

3. Pick of the Week

>> Engineering is more about people than tech [eng-leadership.com]

       

1. Introduction

Null references and values have tormented programmers for years. Tony Hoare, the creator of null references, famously called his invention a “billion-dollar mistake.” Java, in particular, has had a long struggle with null values and the dreaded NullPointerException.

Java 8 introduced the Optional class to address this challenge and ensure proper handling of null and empty results. In this tutorial, we’ll explore performing actions only when all Optional variables contain values, ignoring the action otherwise.

2. Assumptions

This tutorial demonstrates using three Optional variables, but the concepts can be easily extended to handle more. Additionally, let’s declare these variables, which we’ll use throughout this article:

var name = Optional.of("Jean-Luc Picard");
var designation = Optional.of("Captain");
var ship = Optional.of("USS Enterprise D");

In this instance, for the sake of simplicity, we defined Optional<String>. Nevertheless, the principles discussed in the article apply equally to other reference types.

3. Using isPresent()

Optional offers a useful method, isPresent(), to determine if a value is contained within it. This method returns true if a value exists and false if the Optional is empty. Let’s look at the implementation:

var action = false;
if (name.isPresent() && designation.isPresent() && ship.isPresent()) {
    action = true;
}
Assertions.assertTrue(action);

In this example, we create the Optional instances using Optional.of(). Subsequently, we use the isPresent() on each instance and act only if all the values are present. While this approach is notably simple and readable, it becomes cumbersome when dealing with multiple variables.

4. Using flatMap() and map()

Java 8 brought functional programming concepts into the language. With methods like flatMap() and map(), we can now perform actions on values contained in container types, such as Optional. Utilizing flatMap() and map(), we can effectively check and execute actions only when all values are present.

Let’s look at the implementation using this approach:

var action = name.flatMap(n -> designation.flatMap(d -> ship.map(s -> true)));
Assertions.assertEquals(action, Optional.of(true));

In the above example, we chained various Optional instances using flatMap() and map(). These functions are designed to short-circuit; if a value doesn’t exist at any step in the chain, the operation is immediately terminated, and an empty result is returned.

We can verify this behavior by introducing another test case:

var name = Optional.of("Jean-Luc Picard");
var designation = Optional.of("Captain");
var ship = Optional.empty();
var action = name.flatMap(n -> designation.flatMap(d -> ship.map(s -> true)));
Assertions.assertTrue(action.isEmpty());

Here, we can see that the action variable is empty because the ship does not have a value.

While this approach is powerful, it tends to become more verbose when numerous values must be chained together.

5. Using ifPresent()

Alternatively, when we don’t require a return value and only aim to execute an action if all values exist, we can utilize ifPresent() with a lambda expression. Let’s look at the sample code:

name.ifPresent(n -> designation.ifPresent(d -> ship.ifPresent(s -> System.out.println("Perform action instead!"))));

In this scenario, we chain each Optional instance using ifPresent() and execute the action only if all the values exist.

6. Using Stream.of()

Java Streams offers another approach for ensuring actions only happen when all values are present. We can create a stream of Optional values using Stream.of() and utilize the allMatch() method to check if every element within the stream contains a value.

Let’s look at the implementation:

var status = false;
var allPresent = Stream.of(name, designation, ship).allMatch(Optional::isPresent);
if (allPresent) {
    // Perform action if all values present
    status = true;
}
Assertions.assertTrue(status);

In this example, we use allMatch() alongside Optional.isPresent() to verify that all elements within the stream are present.

This provides a concise way to perform the required validation. Unlike the other approaches, adding more optional values doesn’t reduce the readability. This makes Streams a highly scalable solution for handling a growing number of optional values.

7. Conclusion

In this tutorial, we explored different approaches to perform an action only if all the optional values are available. We initially examined the straightforward if…else condition and then explored alternative techniques utilizing functional programming concepts and the Streams API. Ultimately, the most suitable approach depends on the specific context of the situation at hand.

As always, the sample code used in this article is available over on GitHub.

       

1. Overview

When working with Java applications that handle date and time, understanding how to convert between different types is often essential.

In this tutorial, we’ll explore how to convert between ZonedDateTime and Date in Java.

2. Understanding ZonedDateTime and Date

Before diving into conversions, let’s understand the core concepts of ZonedDateTime and Date in Java. This will help us know when and why to convert between these two types.

2.1. ZonedDateTime

ZonedDateTime is part of the Java Date and Time API introduced in Java 8. A ZonedDateTime object contains:

• A local date and time (year, month, day, hour, minute, second, nanosecond)
• A timezone (represented by ZoneId)
• An offset from UTC/Greenwich

This makes ZonedDateTime incredibly useful for applications that require handling different time zones.

2.2. Date

The Date class is a part of the original date and time API from Java’s early versions. It represents a specific instant in time with millisecond precision beginning from the UNIX epoch (January 1, 1970, 00:00:00 GMT).

Date does not contain any time zone information. It is essentially timezone-agnostic, always representing a point in time in UTC. This can lead to confusion if developers mistakenly interpret Date as representing a time in the local time zone.

3. Converting ZonedDateTime to Date

To convert a ZonedDateTime to a Date, we first need to convert the ZonedDateTime to an Instant, as both ZonedDateTime and Instant represent points on the timeline suitable for conversion. Let’s see how we do it:

public static Date convertToDate(ZonedDateTime zonedDateTime) {
    return Date.from(zonedDateTime.toInstant());
}

4. Converting Date to ZonedDateTime

Converting back from a Date to a ZonedDateTime also involves getting an Instant from the Date and then specifying the time zone we want the ZonedDateTime to have:

public static ZonedDateTime convertToZonedDateTime(Date date, ZoneId zone) {
    return date.toInstant().atZone(zone);
}

In this conversion, it’s important to specify the time zone (ZoneId) because a Date object doesn’t contain timezone information. We can get our system’s default ZoneId with the static method ZoneId.systemDefault().

5. Testing Our Methods

Let’s write some unit tests using JUnit to ensure our conversion methods work correctly:

@Test
public void givenZonedDateTime_whenConvertToDate_thenCorrect() {
    ZonedDateTime zdt = ZonedDateTime.now(ZoneId.of("UTC"));
    Date date = DateAndZonedDateTimeConverter.convertToDate(zdt);
    assertEquals(Date.from(zdt.toInstant()), date);
}
@Test
public void givenDate_whenConvertToZonedDateTime_thenCorrect() {
    Date date = new Date();
    ZoneId zoneId = ZoneId.of("UTC");
    ZonedDateTime zdt = DateAndZonedDateTimeConverter.convertToZonedDateTime(date, zoneId);
    assertEquals(date.toInstant().atZone(zoneId), zdt);
}

6. Conclusion

Converting between ZonedDateTime and Date in Java is straightforward once we understand how to handle the conversion points, namely Instant and ZoneId. While ZonedDateTime offers greater functionality and flexibility, Date remains useful in scenarios requiring integration with older Java codebases.

The example code from this article can be found over on GitHub.

       

1. Overview

SSHJ is an open-source Java library that uses SSH protocols for secure communication with remote servers.

In this article, we’ll go through the basic functionality of the SSHJ library.

2. Dependencies

To use the SSHJ library, we’ll have to add the following dependency to the project:

<dependency>
    <groupId>com.hierynomus</groupId>
    <artifactId>sshj</artifactId>
    <version>0.38.0</version>
</dependency>

We can find the latest version of the SSHJ library in Maven Central.

3. SSHJ Library

The SSHJ library helps establish secure connections to remote servers over SSH.

With the SSHJ library, we can handle file upload and download using SCP or SFTP protocols. Plus, we’ve got the added bonus of being able to do local port forwarding and remote port forwarding with it too.

4. Connecting SSH Client

SSH clients can connect to the server using password or public key authentication. The SSHJ library enables us to log in using either method.

4.1. Password Authentication

We can connect to a server via an SSH port using the SSHJ library. The hostname, port, username, and password need to be specified for the SSH connection.

The SSH client connects to the server via password authentication using the authPassword() method:

String host = // ...
int port = // ...
String username = // ...
String password = // ...
SSHClient client = new SSHClient();
client.addHostKeyVerifier(new PromiscuousVerifier());
client.connect(host, port);
client.authPassword(username, password);

As we can see in the above code, we connect the client to the host using password authentication.

4.2. Public Key Authentication

We can connect to the server using the public key as well. For connecting with the public key, we need to have a file entry in the known_hosts file on the server, or we can generate a public key for the remote server on the client machine and copy the public key into authorized SSH keys on the server.

The SSH client connects to the server via public key authentication using the authPublickey() method:

String host = // ... 
String username = // ... 
File privateKeyFile = // ... 
int port = // ...

SSHClient client = new SSHClient();
KeyProvider privateKey = client.loadKeys(privateKeyFile.getPath());
client.addHostKeyVerifier(new PromiscuousVerifier());
client.connect(host, port);
client.authPublickey(username, privateKey);

We can generate a public key for the client and update it on the server to be connected. In the rest of the examples, we’ll log in using the first method, i.e., using a username and password.

5. Executing a Command via SSH

We can execute commands via the SSHJ library using the exec() method on session started by the sshClient connected to the server:

SSHClient client = new SSHClient();
Session session = sshClient.startSession();
Command cmd = session.exec("ls -lsa");
BufferedReader reader = new BufferedReader(new InputStreamReader(cmd.getInputStream()));
String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}
cmd.join(5, TimeUnit.SECONDS);
session.close();

As we can see in the above code, we start a session for sshClient. Then, we execute the ls -lsa command, which lists all files in the directory. We’ve then used BufferedReader to read the output of the command executed.

Similarly, other commands can also be executed here.

6. Uploading/Downloading File via SCP

We can upload a file via SCP. For upload, we use the upload() method on SCPFileTransfer object:

String filePath = // ... 

SSHClient ssh = new SSHClient();
ssh.useCompression();
ssh.newSCPFileTransfer()
  .upload(new FileSystemFile(filePath), "/upload/");

Here, we transfer a file to the upload directory on the server.

The method useCompression() adds zlib compression to preferred algorithms, which can lead to significant speedups. There’s no guarantee it’ll be successfully negotiated. If the client is already connected, then renegotiation is done; otherwise, it simply returns. We can use useCompression() before connecting the client, too.

For SCP file download, we use the download() method on SCPFileTransfer object:

String downloadPath = // ...
String fileName = // ...

SSHClient ssh = new SSHClient();
ssh.useCompression();
ssh.newSCPFileTransfer()
  .download("/upload/" + fileName, downloadPath);

Here, we download the file from the upload directory on the server to the downloadPath location on the client.

The above upload and download methods run the scp command internally, copying files from the local machine to the remote server using an SSH connection and vice versa.

7. Uploading/Downloading File via SFTP

We can upload files via SFTP. For upload, we use the put() method on SFTPClient object:

String filePath = // ...

SSHClient ssh = new SSHClient();
SFTPClient sftp = ssh.newSFTPClient();
sftp.put(new FileSystemFile(filePath), "/upload/");

Here, we transfer the file from the user’s home directory on the client to the upload directory on the server.

For SFTP download, we use the get() method on SFTPClient object:

String downloadPath = // ...
String fileName = // ...

SSHClient ssh = new SSHClient();
SFTPClient sftp = ssh.newSFTPClient();
sftp.get("/upload/" + fileName, downloadPath);
sftp.close();

Here, we download the file from the upload directory on the server to the downloadPath location on the client.

8. Local Port Forwarding

Local port forwarding is used to access services on a remote server as if the services were running on a client:

SSHClient ssh = new SSHClient();
Parameters params = new Parameters(ssh.getRemoteHostname(), 8081, "google.com", 80);
ServerSocket ss = new ServerSocket();
ss.setReuseAddress(true);
ss.bind(new InetSocketAddress(params.getLocalHost(), params.getLocalPort()));
ssh.newLocalPortForwarder(params, ss)
  .listen();

Here, we forward port 80 of the server to port 8081 of the client machine so we can access the website or service hosted on server port 80 from port 8081 on the client machine.

9. Remote Port Forwarding

Using remote port forwarding, we can expose services running on client machines to the remote server network:

SSHClient ssh = new SSHClient();
ssh.getConnection()
  .getKeepAlive()
  .setKeepAliveInterval(5);
ssh.getRemotePortForwarder()
  .bind(new Forward(8083), new SocketForwardingConnectListener(new InetSocketAddress("google.com", 80)));
ssh.getTransport()
  .join();

Here, we forward the service running on the 8083 port of the client to port 80 of the remote server. Effectively, the service running on the client machine at the 8083 port is exposed on port 80 of the remote server.

For both local and remote port forwarding, we need to ensure that proper firewall settings are in place.

10. Check Connection Drops

We need to check connection drops to monitor server connection status and health. SSHJ provides the option of checking connection drops using keep alive:

String hostName = // ...
String userName = // ...
String password = // ...

DefaultConfig defaultConfig = new DefaultConfig();
defaultConfig.setKeepAliveProvider(KeepAliveProvider.KEEP_ALIVE);
SSHClient ssh = new SSHClient(defaultConfig);
ssh.addHostKeyVerifier(new PromiscuousVerifier());
ssh.connect(hostName, 22);
ssh.getConnection()
  .getKeepAlive()
  .setKeepAliveInterval(5);
ssh.authPassword(userName, password);
Session session = ssh.startSession();
session.allocateDefaultPTY();
new CountDownLatch(1).await();
session.allocateDefaultPTY();
session.close();
ssh.disconnect();

In the above code, we can see that the configuration KeepAliveProvider.KEEP_ALIVE enables the keep alive mode for the SSHJ library.

We used setKeepAliveInterval() to set the interval between two keep-alive messages from the client.

11. Conclusion

In this article, we reviewed the basic usage and implementations of the SSHJ library. We figured out how to upload or download files using SCP and SFTP modes. Plus, we saw how to connect the SSH client using a password or public key authentication. Remote and local port forwarding is also achievable via the SSHJ library. Overall, the SSHJ library does most of the things for an SSH client in Java.

As always, the source code examples are available over on GitHub.

       

1. Introduction

When dealing with input data across different sources in Java, we sometimes encounter situations where we must handle data from an InputStream by converting it into a Stream<String>.

In this tutorial, we’ll look at different approaches to achieve this transformation.

2. Converting With BufferedReader and lines() Method

One effective way to convert an InputStream to a Stream<String> is by using a BufferedReader along with its lines() method.

First, we’ll define a byte array bytes containing a sequence of text lines:

byte[] bytes = "Hello\nWorld\nThis\nis\na\ntest".getBytes(StandardCharsets.UTF_8);
InputStream inputStream = new ByteArrayInputStream(bytes);

In the provided code block, we create a byte array named bytes to hold the UTF-8 encoded representation of the provided text lines. Then, we use the ByteArrayInputStream(bytes) to create an InputStream named inputStream from this byte array.

This setup allows us to simulate an InputStream containing the specified text, which will be used in subsequent examples for conversion into a Stream<String>.

Now, let’s see how we can implement this approach in a test scenario:

@Test
void givenInputStream_whenConvertingWithBufferedReader_thenConvertInputStreamToStringStream() throws IOException {
    try (InputStreamReader isr = new InputStreamReader(inputStream, StandardCharsets.UTF_8);
      BufferedReader reader = new BufferedReader(isr)) {
        Stream<String> stringStream = reader.lines();
        String result = stringStream.reduce("", (s1, s2) -> s1 + s2);
        assertEquals("HelloWorldThisisatest", result);
    }
}

In the example above, we create a BufferedReader object wrapped around the InputStream using an InputStreamReader. This allows us to read lines of text efficiently from the InputStream. Additionally, the lines() method of the BufferedReader returns a Stream<String> containing the lines read from the input. Lastly, we process this Stream to concatenate all the String elements into a single result String using the reduce() operation, which we subsequently validate against the expected content using an assertion.

Note that we utilize try-with-resources to ensure that the InputStreamReader and BufferedReader are automatically closed at the end of the try block, releasing associated resources.

3. Converting with Scanner

Another approach involves using Scanner to tokenize the InputStream. Let’s look at a simple implementation:

@Test
void givenInputStream_whenConvertingWithScannerFindAll_thenConvertInputStreamToStringStream() {
    try (Scanner scanner = new Scanner(inputStream, StandardCharsets.UTF_8)) {
        Stream<String> stringStream = scanner.findAll(".+")
          .map(MatchResult::group);
        String result = stringStream.collect(Collectors.joining());
        assertEquals("HelloWorldThisisatest", result);
    }
}

In this approach, we initialize a Scanner object with the InputStream and configure it to use UTF-8 encoding using StandardCharsets.UTF_8.

Afterward, we employ the findAll() method with the regex pattern “.+” to match one or more characters, effectively capturing the content of the InputStream as a sequence of MatchResult.

Then, we map each match result to its matched group using the MatchResult::group, resulting in a Stream<String> containing the matched strings. Subsequently, we use the Collectors.joining() method to concatenate all the strings in the Stream into a single String named result.

4. Conclusion

In conclusion, converting an InputStream into a Stream<String> in Java is made possible using techniques like BufferedReader with its lines() method or leveraging the Scanner with its findAll() method. This allows for efficient processing of text-based data, providing flexibility and scalability when handling an InputStream in our Java applications.

As always, the source code for the examples is available over on GitHub.

       

1. Overview

In this tutorial, we’ll discuss the various ways to implement retry policies in gRPC, a remote procedure call framework developed by Google. gRPC is interoperable in many programming languages but we’ll focus on the Java implementation.

2. Importance of Retry

Applications increasingly rely on a distributed architecture. This approach helps handle heavy workloads through horizontal scaling. It also promotes high availability. However, it also introduces more potential points of failure. Therefore, fault tolerance is crucial when developing applications with multiple microservices.

RPCs can fail temporarily or momentarily because of various factors:

• Network latency or connection drops in the network
• Server not responding due to an internal error
• Busy system resources
• Busy or unavailable downstream services
• Other related issues

Retry is a fault-handling mechanism. A retry policy can help automatically reattempt a failed request based on some condition. It can also define how long or how often the client can retry. This simple pattern can help handle transient failures and increase reliability.

3. RPC Failure Stages

Let’s first understand where a remote procedure call (RPC) can fail:

The client application initiates the request, which the gRPC client library sends to the server. Once received, the gRPC server library forwards the request to the server application’s logic.

A RPC can fail at various stages:

1. Before leaving the client
2. In the server but before reaching the server application logic
3. In the server application logic

4. Retry Support in gRPC

Since retry is an important recovery mechanism, gRPC automatically retries failed requests in special cases and allows developers to define retry policies for greater control.

4.1. Transparent Retry

We must understand that gRPC can safely reattempt failed requests only in cases where the request hasn’t reached the application server logic. Beyond that, the gRPC cannot guarantee the idempotency of the transactions.  Let’s take a look at the overall transparent retry pathway:

As discussed previously, internal retries can happen safely before leaving the client or in the server but before reaching the server application logic. This retry strategy is referred to as transparent retry. Once the server application successfully processes the request, it returns the response and attempts no further retries.

gRPC can perform a single retry when the RPC reaches the gRPC server library because multiple retries can add load to the network. However, it may retry unlimited times when RPC fails to leave the client.

4.2. Retry Policy

To give developers more control, gRPC supports configuring appropriate retry policies for their applications at the individual service or method level. Once the request crosses Stage 2, it comes under the purview of the configurable retry policy. Service owners or publishers can configure the retry policies of their RPCs with the help of service config, a JSON file.

Service owners, typically distribute the service configuration to the gRPC clients using name resolution services such as DNS. However, in cases where name resolution doesn’t provide a service configuration, service consumers or developers can configure it programmatically.

gRPC supports multiple retry parameters:

Notably, the gRPC client uses initialBackoff, maxBackoff, and backoffMultiplier parameters to randomize the delay before retrying requests.

Sometimes, the server might send an instruction in the response metadata, not to retry or try the request after some delay. This is known as server pushback.

Now that we’ve discussed both transparent and policy-based retry features of gRPC, let’s summarize how gRPC manages retries overall:

5. Programmatically Apply Retry Policy

Let’s say we have a service that can broadcast messages to the citizens by calling an underlying notification service that sends SMS to cell phones. The government uses this service to make announcements on emergencies. The client application using this service must have a retry strategy to mitigate errors due to transient failures.

Let’s explore further on this.

5.1. High-Level Design

First, let’s look at the interface definition in the broadcast.proto file:

syntax = "proto3";
option java_multiple_files = true;
option java_package = "com.baeldung.grpc.retry";
package retryexample;
message NotificationRequest {
  string message = 1;
  string type = 2;
  int32 messageID = 3;
}
message NotificationResponse {
  string response = 1;
}
service NotificationService {
  rpc notify(NotificationRequest) returns (NotificationResponse){}
}

The broadcast.proto file defines NotificationService with a remote method notify() and two DTOs NotificationRequest and NotificationResponse.

Overall, let’s see the classes used in the client and server sides of the gRPC application:

Later, we can use the broadcast.proto file for generating the supporting Java source code for implementing the NotificationService. The Maven plugin generates the classes NotificationRequest, NotificationResponse, and NotificationServiceGrpc.

The GrpcBroadcastingServer class on the server side uses the ServerBuilder class to register NotificationServiceImpl to broadcast messages. The client-side class GrpcBroadcastingClient uses the ManagedChannel classes of the gRPC library to manage the channel to perform the RPCs.

The service config file retry-service-config.json outlines the retry policy:

{
     "methodConfig": [
         {
             "name": [
                 {
                      "service": "retryexample.NotificationService",
                      "method": "notify"
                 }
              ],
             "retryPolicy": {
                 "maxAttempts": 5,
                 "initialBackoff": "0.5s",
                 "maxBackoff": "30s",
                 "backoffMultiplier": 2,
                 "retryableStatusCodes": [
                     "UNAVAILABLE"
                 ]
             }
         }
     ]
}

Earlier, we understood the retry policies such as maxAttempts, exponential backoff parameters, and retryableStatusCodes. When the client invokes the remote procedure notify() in NotificationService as defined earlier in the broadcast.proto file, the gRPC framework enforces the retry settings.

5.2. Implement Retry Policy

Let’s take a look at the class GrpcBroadcastingClient:

public class GrpcBroadcastingClient {
    protected static Map<String, ?> getServiceConfig() {
        return new Gson().fromJson(new JsonReader(new InputStreamReader(GrpcBroadcastingClient.class.getClassLoader()
            .getResourceAsStream("retry-service-config.json"), StandardCharsets.UTF_8)), Map.class);
    }
    public static NotificationResponse broadcastMessage() {
        ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
          .usePlaintext()
          .disableServiceConfigLookUp()
          .defaultServiceConfig(getServiceConfig())
          .enableRetry()
          .build();
        return sendNotification(channel);
    }
    
    public static NotificationResponse sendNotification(ManagedChannel channel) {
        NotificationServiceGrpc.NotificationServiceBlockingStub notificationServiceStub = NotificationServiceGrpc
          .newBlockingStub(channel);
        NotificationResponse response = notificationServiceStub.notify(NotificationRequest.newBuilder()
          .setType("Warning")
          .setMessage("Heavy rains expected")
          .setMessageID(generateMessageID())
          .build());
        channel.shutdown();
        return response;
    }
}

The broadcast() method builds the ManagedChannel object with the necessary configurations. Then, we pass it to sendNotification() which further invokes the notify() method on the stub.

The methods in the ManagedChannelBuilder class that play a crucial role in setting up the service config consisting of the retry policy are:

• disableServiceConfigLookup(): Explicitly disables the service config lookup through name resolution
• enableRetry(): Enables per-method configuration for retry
• defaultServiceConfig(): Explicitly sets up the service configuration

The method getServiceConfig() reads the service config from the retry-service-config.json file and returns a Map representation of its content. Subsequently, this Map is passed on to the defaultServiceConfig() method in the ManagedChannelBuilder class.

Finally, after creating the ManagedChannel object, we call the notify() method of the notificationServiceStub object of type NotificationServiceGrpc.NotificationServiceBlockingStub to broadcast the message. The policy works for non-blocking stubs as well.

It’s advisable to use a dedicated class for creating ManagedChannel objects. This allows for centralized management, including the configuration of retry policies.

To demonstrate the retry feature, the NotificationServiceImpl class in the server is designed to be randomly out of service. Let’s take a look at the GrpcBroadcastingClient in action:

@Test
void whenMessageBroadCasting_thenSuccessOrThrowsStatusRuntimeException() {
    try {
        NotificationResponse notificationResponse = GrpcBroadcastingClient.sendNotification(managedChannel);
        assertEquals("Message received: Warning - Heavy rains expected", notificationResponse.getResponse());
    } catch (Exception ex) {
        assertTrue(ex instanceof StatusRuntimeException);
    }
}

The method invokes sendNotification() on the GrpcBroadcastingClient class to invoke the server-side remote procedure to broadcast messages. We can examine the logs to verify the retries:

6. Conclusion

In this article, we explored the retry policy feature in the gRPC library. The ability to set up the policy declaratively through a JSON file is a powerful feature. However, we should use it for testing scenarios or when the service config is unavailable during the name resolution.

Retrying failed requests can lead to unpredictable outcomes, hence we should be careful in setting it only for idempotent transactions.

As usual, the code used for this article is available over on GitHub.

       

1. Overview

When we work with Java, dealing with arrays is a fundamental task. We often need to access the first and last elements of an array.

In this quick tutorial, we’ll explore how to efficiently get the first and last elements of an array in Java.

2. Short Introduction to Java Arrays

In Java, an array is a data structure that allows us to store a fixed-size sequence of elements.

The length property of an array returns the number of elements in the array. It’s important to note that length is a property, not a method, i.e., we access it without parentheses: array.length.

Random access in Java arrays is fast and efficient. Also, since Java arrays provide direct memory access to elements based on their indexes, accessing any element within the array has the same time complexity, regardless of the index.

Next, let’s see how to obtain the first and the last elements from an array.

3. Obtaining the First and the Last Elements

We’ve mentioned that it’s efficient to access elements in an array by indexes. Java arrays are zero-indexed, meaning the index of the first element is 0, the index of the second element is 1, and so on.

Therefore, we can use array[0] to access the first element in array. Moreover, we can determine the index of the last element by subtracting one from the length property: array.length – 1.

So next, let’s see an example of how to access the first and last elements from a String array:

String[] array = { "java", "kotlin", "c", "c#", "go", "python", "rust", "ruby" };
assertEquals("java", array[0]);
assertEquals("ruby", array[array.length - 1]);

As the example shows, we have a String array containing eight String values. We successfully obtained the first and the last elements using array[0] and array[array.length – 1].

4. What if the Array Is Empty?

We’ve learned how to retrieve the first and the last elements from an array using indexes. However, an array can be empty in Java.

Next, let’s see what happens if we access the first and the last elements from an empty array:

String[] array = new String[] {};
assertThrows(ArrayIndexOutOfBoundsException.class, () -> {String failing = array[0];});
assertThrows(ArrayIndexOutOfBoundsException.class, () -> {String failing = array[array.length - 1];});

The test above shows that accessing an empty array by indexes raises the ArrayIndexOutOfBoundsException.

A straightforward way to determine if an array is empty is to check whether its length equals 0:

String[] array = new String[] {};
assertEquals(0, array.length);

Therefore, it’s recommended to ensure the array isn’t empty before accessing its element:

if (array.length > 0){
    // ... access elements by index
} else {
    // ... handle the empty array case
}

The above example shows an if-else-based array empty check.

5. Conclusion

In this article, we’ve delved into retrieving the first and the last elements of an array:

• The first element – array[0]
• The last element – array[array.length – 1]

Accessing an array by its indexes is efficient. However, it’s imperative to verify that the array isn’t empty before attempting to retrieve elements by indexes.

As always, the complete source code for the examples is available over on GitHub.

       

1. Introduction

In this article, we’re going to have a look at the JavaParser library. We’ll see what it is, what we can do with it, and how to use it.

2. What Is JavaParser?

JavaParser is an open-source library for working with Java sources. It allows us to parse Java source code into an abstract syntax tree (AST). Once we’ve done this, we can analyze the parsed code, manipulate it, and even write new code.

Using JavaParser, we can parse source code written in Java up to Java 18. This includes all stable language features but may not include any preview features.

3. Dependencies

Before we can use JavaParser, we need to include the latest version in our build, which is 3.25.10 at the time of writing.

The main dependency that we need to include is javaparser-core. If we’re using Maven, we can include this dependency in our pom.xml file:

<dependency>
    <groupId>com.github.javaparser</groupId>
    <artifactId>javaparser-core</artifactId>
    <version>3.25.10</version>
</dependency>

Or if we’re using Gradle, we can include it in our build.gradle file:

implementation("com.github.javaparser:javaparser-core:3.25.10")

At this point, we’re ready to start using it in our application.

Two additional dependencies are available as well. The dependency com.github.javaparser:javaparser-symbol-solver-core provides a means to analyze the parsed AST to find the relationships between Java elements and their declarations. The dependency com.github.javaparser:javaparser-core-serialization provides a means to serialize the parsed AST to and from JSON.

4. Parsing Java Code

Once we have the dependencies set up in our application, we’re ready to go. Parsing of Java code always starts with the StaticJavaParser class. This gives us several different mechanisms for parsing code, depending on what we’re parsing and where it’s coming from.

4.1. Parsing Source Files

The first thing we’ll look at parsing is the entire source files. We can do this with the StaticJavaParser.parse() method. Several overloaded alternatives allow us to provide the source code in different ways – directly as a string, as a File on the local filesystem, or as an InputStream or Reader for some resource. All of these work the same way and are simply convenient ways to provide the code to be parsed.

Let’s see it in action. Here, we’ll attempt to parse the provided source code and generate a CompilationUnit as a result:

CompilationUnit parsed = StaticJavaParser.parse("class TestClass {}");

This represents our AST and lets us inspect and manipulate the parsed code.

4.2. Parsing Statements

Individual statements are at the other end of the spectrum of the code that we can parse. We do this using the StaticJavaParser.parseStatement() method. Unlike with source files, there’s only a single version of this that takes a single string containing the statement to parse.

This method returns a Statement object that represents the parsed statement:

Statement parsed = StaticJavaParser.parseStatement("final int answer = 42;");

4.3. Parsing Other Constructs

JavaParser can also parse many other constructs, covering the entire Java language up to Java 18. Each construct has a separate, dedicated parse method and returns an appropriate type representing the parsed code. For example, we can use parseAnnotation() for parsing annotations, parseImport() for import statements, parseBlock() for parsing blocks of statements, and many more.

Internally, JavaParser will use the exact same code for parsing the various parts of our code. For example, when parsing a block using parseBlock(), JavaParser will ultimately end up in the same code as is called directly by parseStatement(). This means we can rely on these different parsing methods working the same for the same subsets of code.

We do need to know exactly what type of code we’re parsing in order to select the correct parsing method. For example, using the parseStatement() method to parse a class definition will fail.

4.4. Malformed Code

If parsing fails, the JavaParser will throw a ParseProblemException indicating exactly what was wrong with the code. For example, if we attempt to parse a malformed class definition, then we’ll get something like:

ParseProblemException parseProblemException = assertThrows(ParseProblemException.class,
    () -> StaticJavaParser.parse("class TestClass"));
assertEquals(1, parseProblemException.getProblems().size());
assertEquals("Parse error. Found <EOF>, expected one of  \"<\" \"extends\" \"implements\" \"permits\" \"{\"", 
    parseProblemException.getProblems().get(0).getMessage());

We can see from this error message that the problem is that the class definition is wrong. In Java, such a statement must be followed by either a “<“ – for a generic definition, the extends or implements keyword, or else a “{“ to start the actual body of the class.

5. Analyzing Parsed Code

Once we’ve parsed some code, we can start analyzing it to learn from it. This is similar to reflection within a running application, only on the parsed source code instead of the currently running code.

5.1. Accessing Parsed Elements

Once we’ve parsed some source code, we can query the AST to access individual elements. Exactly how we do this varies depending on the elements we want to access and what we’ve parsed.

For example, if we’ve parsed a source file into a CompilationUnit, then we can access a class that we expect to be present using getClassByName():

Optional<ClassOrInterfaceDeclaration> cls = compilationUnit.getClassByName("TestClass");

Note that this returns an Optional<ClassOrInterfaceDeclaration>. Optional is used because we can’t guarantee the type is present in this compilation unit. In other cases, we might be able to guarantee the presence of elements. For example, a class will always have a name, so ClassOrInterfaceDeclaration.getName() doesn’t need to return an Optional.

At every stage, we can only directly access elements that are at the outermost level of what we’re currently working with. For example, if we’ve got a CompilationUnit from parsing a source file, then we can access the package declaration, the import statements, and the top-level types, but we can’t access the members within those types. However, once we access one of these types, we can then access the members within it.

5.2. Iterating Parsed Elements

In some cases, we may not know exactly what elements are present in our parsed code, or else we simply want to work with all of a certain type of element instead of only one.

Each of our AST types can access an entire range of appropriate nested elements. Exactly how this works depends on what we want to work with. For example, we can extract all of the import statements out of a CompilationUnit using:

NodeList<ImportDeclaration> imports = compilationUnit.getImports();

No Optional is needed, as this is guaranteed to return a result. However, if no imports were present, this result might be an empty list.

Once we’ve done this, we can treat this as any collection. The NodeList type implements java.util.List correctly so we can work with it exactly as any other list.

5.3. Iterating the Entire AST

In addition to extracting exactly one type of element from our parsed code, we can also iterate over the entire parsed tree. All AST types from JavaParser implement the visitor pattern, allowing us to visit every element in our parsed source code with a custom visitor:

compilationUnit.accept(visitor, arg);

There are then two standard types of visitors that we can use with this. Both of these have a visit() method for each possible AST type, which takes a state argument that’s passed into the accept() call.

The simplest of these is VoidVisitor<A>. This has one method for every AST type and no return values. We then have an adapter type – VoidVisitorAdapter – that gives us a standard implementation to help ensure that the entire tree is correctly called.

We then only need to implement the methods that we’re interested in – for example:

compilationUnit.accept(new VoidVisitorAdapter<Object>() {
    @Override
    public void visit(MethodDeclaration n, Object arg) {
        super.visit(n, arg);
        System.out.println("Method: " + n.getName());
    }
}, null);

This will output a log message for every method name in the source file, regardless of where they are. The fact that this recurses over the entire tree structure means that these methods can be in top-level classes, inner classes, or even anonymous classes within other methods.

The alternative is GenericVisitor<R, A>. This works similarly to VoidVisitor, except that its visit() methods have a return value. We also have adapter classes here, depending on how we want to collect the return values from each method. For example, GenericListVisitorAdaptor will force us to have our return type from each method be a List<R> instead and merge all of these lists together:

List<String> allMethods = compilationUnit.accept(new GenericListVisitorAdapter<String, Object>() {
    @Override
    public List<String> visit(MethodDeclaration n, Object arg) {
        List<String> result = super.visit(n, arg);
        result.add(n.getName().asString());
        return result;
    }
}, null);

This will return a list that contains the names of every method in the entire tree.

6. Outputting Parsed Code

In addition to parsing and analyzing our code, we can also output it again as a string. This can be useful for many reasons – for example, if we want to extract and output only specific sections of the code.

The easiest way to achieve this is to simply use the standard toString() method. All of our AST types correctly implement this and will produce formatted code. Note that this might not be formatted exactly as it was when we parsed the code, but it’ll still follow relatively standard conventions.

For example, if we parse the following code:

package com.baeldung.javaparser;
import java.util.List;
class TestClass {
private List<String> doSomething()  {}
private class Inner {
private String other() {}
}
}

When we format it, we’ll get this as the output:

package com.baeldung.javaparser;
import java.util.List;
class TestClass {
    private List<String> doSomething() {
    }
    private class Inner {
        private String other() {
        }
    }
}

The other method we can use for formatting code is using the DefaultPrettyPrinterVisitor. This is a standard visitor class that will handle formatting. This gives us the advantage of configuring some aspects of how the output is formatted. For example, if we wanted to indent with two spaces instead of four, we could write:

DefaultPrinterConfiguration printerConfiguration = new DefaultPrinterConfiguration();
printerConfiguration.addOption(new DefaultConfigurationOption(DefaultPrinterConfiguration.ConfigOption.INDENTATION,
    new Indentation(Indentation.IndentType.SPACES, 2)));
DefaultPrettyPrinterVisitor visitor = new DefaultPrettyPrinterVisitor(printerConfiguration);
compilationUnit.accept(visitor, null);
String formatted = visitor.toString();

7. Manipulating Parsed Code

Once we’ve parsed some code into an AST, we’re also able to make changes to it. Since this is now just a Java object model, we can treat it as any other object model, and JavaParser gives us the ability to change most aspects of it freely.

Combining this with the ability to output our AST back as working source code means that we can then manipulate parsed code, make changes to it, and provide the output in some form. This could be useful for IDE plugins, code compilation steps, and much more.

This can be used in any way that we have access to the appropriate AST elements – whether that’s from directly accessing them, iterating with a visitor, or whatever makes sense.

For example, if we wanted to uppercase every single method name in a piece of code, then we could do something like:

compilationUnit.accept(new VoidVisitorAdapter<Object>() {
    @Override
    public void visit(MethodDeclaration n, Object arg) {
        super.visit(n, arg);
        
        String oldName = n.getName().asString();
        n.setName(oldName.toUpperCase());
    }
}, null);

This uses a simple visitor to visit every method declaration in our source tree and uses the setName() method to give each method a new name. The new name is then simply the old name in uppercase.

Once this is done, the AST is updated in place. We can then format it however we wish, and the newly formatted code will reflect our changes.

8. Summary

We’ve seen here a quick introduction to JavaParser. We’ve shown how to get started with it and some of the things we can achieve using it. Next time you need to manipulate some Java code, why not try it out?

All of the examples are available over on GitHub.

       

1. Introduction

In this tutorial, we’ll explore different approaches to finding the second smallest element in an array using Java.

2. Problem Statement

Given an array of integers, the task is to find the second smallest element within the array. This value represents the second-lowest integer present in the array, assuming there are at least two distinct elements.

There are two circumstances where no second smallest element can be found in an array:

• If the input array is empty (length 0) or contains only one element, there’s no second smallest element to identify.
• If all elements in the array are identical, there’s no distinct second smallest element.

In such cases, we’ll return -1 to indicate no second smallest number was found in the given array.

Let’s take a look at the examples below:

Input: [4, 2, 8, 1, 3] Output: 2 
Input: [1, 1, 1] Output: -1
Input: [1] Output: -1
Input: [] Output: -1

3. Using Array Sorting

One straightforward approach is to sort the array in the ascending order and then return the second element, which will be the second smallest integer. Here’s the code to find the second smallest integer in an array by sorting the array:

int[] arr = {5, 2, 9, 1, 7};
Arrays.sort(arr);
result = arr[1];

However, this approach has a limitation. If the array contains duplicate elements (e.g., {5, 2, 9, 1, 7, 1}), directly accessing the second element after sorting might not give the second smallest distinct element.

To address duplicates, we can modify the sorting approach:

int usingArraySort(int[] arr) {
    Arrays.sort(arr);
    int smallest = arr[0];
    for (int i = 1; i < arr.length; i++) {
        if (arr[i] != smallest) {
            return arr[i];
        }
    }
    return -1;
}

This modified approach iterates through the sorted array after sorting. It keeps track of the smallest element encountered so far. If it encounters a distinct element (different from the current smallest), it updates the result with that element and breaks the loop. This ensures it finds the second smallest distinct element:

assertEquals(4, usingArraySort(new int[] {5, 3, 8, 9, 6, 8, 4, 4}));
assertEquals(-1, usingArraySort(new int[] {5}));
assertEquals(3, usingArraySort(new int[] {5, 3}));
assertEquals(-1, usingArraySort(new int[] {5, 5, 5, 5, 5}));

Sorting the array is a familiar concept for beginners, and the logic is straightforward. However, Arrays.sort() typically has a time complexity of O(n log n) in the average and worst cases, where n is the number of elements in the array. This can be inefficient for large arrays.

4. Using Single Pass Through

This approach efficiently finds the second smallest element in an array by iterating through it only once. It avoids the overhead of sorting and leverages conditional statements to update potential candidates for the smallest and second smallest elements.

Here’s the code for this approach:

int usingSinglePassThrough(int[] arr) {
    int smallest = Integer.MAX_VALUE;
    int secondSmallest = Integer.MAX_VALUE;
    for (int num : arr) {
        if (num < smallest) {
            secondSmallest = smallest;
            smallest = num;
        } else if (num < secondSmallest && num != smallest) {
            secondSmallest = num;
        }
    }
    if (secondSmallest == Integer.MAX_VALUE) {
        return -1;
    } else {
        return secondSmallest;
    }
}

assertEquals(4, usingSinglePassThrough(new int[] {5, 3, 8, 9, 6, 8, 4, 4}));
assertEquals(-1, usingSinglePassThrough(new int[] {5}));
assertEquals(3, usingSinglePassThrough(new int[] {5, 3}));
assertEquals(-1, usingSinglePassThrough(new int[] {5, 5, 5, 5, 5}));

In the worst-case scenario, the loop executes for all elements in the array. Therefore, the time complexity of this approach is O(n), which signifies a linear relationship between the number of elements and the execution time. Overall, this approach avoids sorting the entire array, making it potentially faster, especially for larger arrays.

5. Using Min Heap

This approach leverages a min-heap data structure to efficiently find the second smallest element in an array. A min-heap is a priority queue where the element with the minimum value always resides at the root. By strategically manipulating the heap size, we can ensure it holds the smallest and potentially the second smallest elements.

Here’s the code implementing this approach:

int usingMinHeap(int[] arr) {
    if (arr.length < 2) {
        return -1;
    }
    
    PriorityQueue<Integer> minHeap = new PriorityQueue<>();
    for (int num : arr) {
        if (minHeap.isEmpty() || num != minHeap.peek()) {
            minHeap.offer(num); 
        }
    }
    // all elements were the same if minHeap size is less than 2
    if (minHeap.size() < 2) {
        return -1;
    }
    minHeap.poll(); // Remove the smallest element
    return minHeap.peek(); // Second smallest element is at the root
}

We first check if the array length is less than 2. If so, we return -1 as there’s no second smallest element. Next, we create a PriorityQueue object minHeap. By default, PriorityQueue implements a min-heap, so the element with the minimum value is at the root.

We iterate through the array, adding each element to the minHeap using offer(). In each iteration, we consider two conditions:

• If the heap is empty, any element can be added as there’s no smaller element yet.
• If the current element is distinct from the smallest element in the heap, it can be added. This ensures that duplicate elements with the same value as the smallest aren’t added multiple times.

After processing the entire array, we check if the minHeap size is less than 2. This indicates that all elements were the same. In this case, we return -1 as there’s no second smallest.

Otherwise, we remove the smallest element from the min-heap using poll() and return the second smallest element from the root of the min-heap using peek().

Let’s validate our solution using the test cases:

assertEquals(4, usingMinHeap(new int[] {5, 3, 8, 9, 6, 8, 4, 4}));
assertEquals(-1, usingMinHeap(new int[] {5}));
assertEquals(3, usingMinHeap(new int[] {5, 3}));
assertEquals(-1, usingMinHeap(new int[] {5, 5, 5, 5, 5}));

This approach can be more efficient than sorting for larger arrays. However, for very small arrays, the overhead of creating and maintaining the min-heap might be less efficient compared to simpler approaches.

The min-heap approach can be considered to have an average and worst-case time complexity of O(n), which is more efficient than sorting algorithms.

6. Conclusion

In this article, we’ve explored a few approaches to finding the second smallest number in an array. Sorting the entire array might be suitable for smaller datasets as it’s a familiar concept. However, for larger datasets, single pass through or min heap are better solutions.

As always, the source code for the examples is available over on GitHub.

       

1. Introduction

A power of 2 is a number that can be expressed as 2 raised to some integer power, such as 2, 4, 8, 16, and so on. In Java, there are several ways to determine if a given number is a power of 2, including using logarithms, bitwise operations, loop division, and built-in methods. In this tutorial, we’ll explore these different methods and provide examples of how to implement them in Java.

2. Loop Division

One way to check if a number is a power of 2 is to iteratively divide the number by 2 until it reaches 1. If the number is a power of 2, it’ll result in 1 after a finite number of divisions. Let’s see how this technique is implemented:

boolean isPowerOfTwoUsingLoopDivision(int n) {
    while (n != 1 && n % 2 == 0) {
        n /= 2;
    }
    return n == 1;
}

In this method, we use a while loop to divide the number by 2 until it becomes 1. If the number is a power of 2, then it’ll be divided only a few times before it becomes 1. However, for the number that is not a power of 2, the loop will keep dividing until it encounters an odd number:

assertTrue(isPowerOfTwoUsingLoopDivision(256));
assertFalse(isPowerOfTwoUsingLoopDivision(100));

3. Using Bitwise & Operations

A more efficient method involves leveraging bitwise operations. In binary representation, a power of 2 has only one set bit (1) and all other bits set to 0. This characteristic allows us to exploit bitwise operators for a faster solution. Let’s implement this technique:

boolean isPowerOfTwoUsingBitwiseOperation(int n) {
    return (n != 0) && ((n & (n - 1)) == 0);
}

This method first checks if n is not zero (since zero isn’t a power of 2). Then, it uses the bitwise AND operator (&) to perform a clever trick. The expression n & (n – 1) essentially turns off the least significant set bit in n. If n was a power of 2 with only one set bit, this operation would result in zero. This is because both numbers will have their single set bits at different positions, leading to a 0 after the AND operation:

assertTrue(isPowerOfTwoUsingBitwiseOperation(256));
assertFalse(isPowerOfTwoUsingBitwiseOperation(100));

This approach is fast and efficient due to its simplicity and by leveraging a bitwise operation. However, it might be less intuitive for beginners and require a basic understanding of bitwise operations.

4. Counting Set Bits

This method involves counting the number of set bits (1s) in the binary representation of the number. Since a power of 2 has only one set bit, counting the set bits can reveal if the number is a power of 2. Here’s an example implementation:

boolean isPowerOfTwoUsingSetBitCount(int n) {
    int count = 0;
    while (n > 0) {
        count += n & 1;
        n >>= 1;
    }
    return count == 1;
}

This approach iterates through each bit of n to check if it’s set (1) using the bitwise AND with 1 (n & 1). It then accumulates the count of set bits. Next, we shift the bits of n to the right by one position using the right shift operator (>>). This operation effectively moves to the next bit in the binary representation of n.

After processing all bits, it checks if the count is equal to 1, indicating a power of 2:

assertTrue(isPowerOfTwoUsingSetBitCount(256));
assertFalse(isPowerOfTwoUsingSetBitCount(100));

This method might be useful in scenarios where counting set bits is required for other purposes.

5. Using Integer.highestOneBit()

Java provides a built-in method Integer.highestOneBit(int) that returns the integer with the highest bit set (leftmost 1) to 1 and all lower bits set to 0. Let’s see how we can leverage this method:

boolean isPowerOfTwoUsingHighestOneBit(int n) {
    return n > 0 && (n == Integer.highestOneBit(n));
}

This method ensures n is positive and compares n with the result of Integer.highestOneBit(). If n is a power of 2, it’ll have only one set bit, and both values will be equal:

assertTrue(isPowerOfTwoUsingHighestOneBit(256));
assertFalse(isPowerOfTwoUsingHighestOneBit(100));

By ensuring the number is positive and comparing it with its highest set bit, this approach offers a concise solution. However, it might entail slightly more overhead compared to bitwise operations.

6. Using Logarithm

Lastly, we can use the logarithm base 2 to check the power of 2. The base-2 logarithm of a number is the exponent to which 2 must be raised to get that number. If the logarithm (base 2) of a number is a whole number, then the number is a power of 2. Here’s the Java code demonstrating this method:

boolean isPowerOfTwoUsingLogarithm(int n) {
    return (Math.log(n) / Math.log(2)) % 1 == 0;
}

In this method, we divide the natural logarithm of n by the natural logarithm of 2 Math.log(2). If the result is a whole number, then the number is a power of 2. We use the modulo operator % to check if the result is a whole number. If the result is 0, then the number is a power of 2:

assertTrue(isPowerOfTwoUsingLogarithm(256));
assertFalse(isPowerOfTwoUsingLogarithm(100));

The advantage of this method is that it is easy to understand and implement. However, it can be slower for large numbers.

7. Summary

Each approach has its advantages and considerations. Here’s a summary.

8. Conclusion

In this article, we’ve explored a few ways to determine if a number is a power of 2 in Java. For most applications, bitwise operations are the most efficient and effective method.

As always, the source code for the examples is available over on GitHub.

       

1. Overview

In this tutorial, we’ll learn about monads, and how they can help us deal with effects. We’ll learn about the essential methods enabling us to chain monads and operations: map() and flatMap(). Throughout the article, we’ll explore the APIs of a few popular monads from the Java ecosystem, focusing on their practical applications.

2. Effects

In functional programming, “effects” typically refer to operations that cause changes beyond the scope of the function or component.

To apply the functional programming paradigm while dealing with these effects, we can wrap our operation or data inside a container. We can think of monads as containers that allow us to handle the effects outside the function’s scope, preserving the function’s purity.

For instance, let’s say we have a function that divides two double numbers:

double divide(double dividend, double divisor) {
    return dividend / divisor;
}

Although it looks like a pure function, when we pass zero as the value for the divisor parameter, the function produces a side effect by throwing an ArithmeticException. However, we can use a monad to wrap the function’s result and contain its effect.

Let’s change the function and make it return an Optional<Double> instead:

Optional<Double> divide(double dividend, double divisor) {
    if (divisor == 0) {
        return Optional.empty();
    }
    return Optional.of(dividend / divisor);
}

As we can see, the function is no longer producing side effects when we try to divide by zero.

Here are a few other popular Java examples of monads that help us deal with various effects:

• Optional<> – dealing with nullability
• List<>, Stream<> – managing collections of data
• Mono<>, CompletableFuture<> – dealing with concurrency and I/O
• Try<>, Result<> – dealing with errors
• Either<> – dealing with duality

3. Functors

When we create a monad, we need to allow it to change its encapsulated object or operation, while keeping the same container type.

Let’s take Java Streams as an example. If in the “real world”, an instance of type Long can be converted to an Instant by calling the method Instant.ofEpochSeconds(), this relation must be preserved in the world of Streams.

To achieve this, the Stream API exposes a higher-order function that “lifts” the original relationship. This concept is also known as a “functor” and the method that allows transforming the encapsulated type is typically named “map“:

Stream<Long> longs = Stream.of(1712000000L, 1713000000L, 1714000000L);
Stream<Instant> instants = longs.map(Instant::ofEpochSecond);

Although “map” is the typical term for this function type, the specific method name itself isn’t essential for an object to qualify as a functor. For example, the CompletableFuture monad provides a method called thenApply() instead:

CompletableFuture<Long> timestamp = CompletableFuture.completedFuture(1713000000L);
CompletableFuture<Instant> instant = timestamp.thenApply(Instant::ofEpochSecond);

As we can see, both Stream and CompletableFuture containers expose methods that enable us to apply all the operations supported by the encapsulated data:

4. Binding

Binding is a key characteristic of a monad that allows us to chain multiple computations in a monadic context. In other words, we can avoid double nesting by replacing map() with binding.

4.1. Nested Monads

If we solely rely on functors to sequence the operations, we’ll eventually end up with nested containers. Let’s use Project Reactor‘s Mono monad for this example.

Let’s assume we have two methods that allow us to fetch Author and Book entities reactively:

Mono<Author> findAuthorByName(String name) { /* ... */ }
Mono<Book> findLatestBookByAuthorId(Long authorId) { /* ... */ }

Now, if we start with the author’s name, we can use the first method and fetch his details. The result is a Mono<Author>:

void findLatestBookOfAuthor(String authorName) {
    Mono<Author> author = findAuthorByName(authorName);
    // ...
}

After that, we may be tempted to use the map() method to change the content of the container from an Author to his latest Book:

Mono<Mono<Book>> book = author.map(it -> findLatestBookByAuthorId(it.authorId());

But, as we can see, this results in a nested Mono container. This happens because findLatestBookByAuthorId() returns a Mono<Author> while map() wraps the result yet another time.

4.2. flatMap()

However, if we use binding instead, we eliminate the extra container and flatten the structure. The name “flatMap” has been commonly adopted for the bind method, although there are a few exceptions where it’s called differently:

void findLatestBookOfAuthor(String authorName) {
    Mono<Author> author = findAuthorByName(authorName);
    Mono<Book> book = author.flatMap(it -> findLatestBookByAuthorId(it.authorId()));
    // ...
}

We can now simplify the code a bit by in-lining the operations, and introducing an intermediate map() that translates from the Author to its authorId:

void findLatestBookOfAuthor(String authorName) {
    Mono<Book> book = findAuthorByName(authorName)
      .map(Author::authorId)
      .flatMap(this::findLatestBookByAuthorId));
    // ...
}

As we can see, combining map() and flatMap() is an efficient way of working with monads, allowing us to define a sequence of transformations in a declarative fashion.

5. Practical Use-Cases

As we have seen in the previous code examples, monads help us deal with effects by offering an extra layer of abstraction. Most of the time, they enable us to focus on the main scenario and handle the corner cases outside of the main logic.

5.1. The “Railroad” Pattern

Binding monads like this is also known as the “railroad” pattern. We can visualize the main flow by imagining a railroad going into a straight line. Additionally, if something unexpected happens, we’ll switch from the main railroad to a secondary, parallel one.

Let’s think about validating a Book object. We start by validating the book’s ISBN, then check the authorId and, finally, we validate the book’s genre:

void validateBook(Book book) {
    if (!validIsbn(book.getIsbn())) {
        throw new IllegalArgumentException("Invalid ISBN");
    }
    Author author = authorRepository.findById(book.getAuthorId());
    if (author == null) {
        throw new AuthorNotFoundException("Author not found");
    }
    if (!author.genres().contains(book.genre())) {
        throw new IllegalArgumentException("Author does not write in this genre");
    }
}

We can use vavr’s Try monad and apply the railroad pattern to chain these validations together:

void validateBook(Book bookToValidate) {
    Try.ofSupplier(() -> bookToValidate)
      .andThen(book -> validateIsbn(book.getIsbn()))
      .map(book -> fetchAuthor(book.getAuthorId()))
      .andThen(author -> validateBookGenre(bookToValidate.genre(), author))
      .get();
}
void validateIsbn(String isbn) { /* ... */ }
Author fetchAuthor(Long authorId) { /* ... */ }
void validateBookGenre(String genre, Author author) { /* ... */ }

As we can see, the API exposes methods like andThen(), useful for functions where we don’t need their response. Their purpose is to check for failure, and, if required, to switch to the secondary channel. On the other hand, methods such as map() and flatMap() are meant to move the flow further, creating a new Try<> monad that wraps the response of the function, in this case, the Author object:

5.2. Recovering

In some cases, the APIs allow us to recover from the secondary channel back to the main one. Most of the time, this requires us to supply a fallback value. For instance, when using the API of Try<>, we can use the method recover() to switch from the “failure” channel back into the main one:

5.3. Other Examples

Now that we’ve learned how monads work and how to bind them using the railroad pattern, we understand that the actual names of the various methods are irrelevant. Instead, we should focus on their purpose. Most of the methods from a monad’s API:

• transform the underlying data
• if needed, switch between the channels

For example, the Optional monad uses map() and flatMap() to transform its data, respectively filter() and or() to potentially switch between “empty” and “present” states.

On the other hand, CompletableFuture uses methods like thenApply() and thenCombine() instead of map() and flatMap(), and allows us to recover from the failure channel via exceptionally().

6. Conclusion

In this article, we discussed about monads and their main characteristics. We used practical examples to understand how they can help us deal with effects such as managing collections, concurrency, nullability, exceptions etc. After that, we learned how to apply the “railroad” pattern to bind monads and push all these effects outside our component’s scope.

As always, the complete source code can be found over on GitHub.

       

1. Introduction

In this tutorial, we’ll explore the possibilities within Java for supplying an enum value from a constant to an annotation. To understand the main drivers of the proposed design decisions, we’ll start with the problem statement, followed by a demo use case.

After that, we’ll define the ideal solution, understand the Java language limitations, and finally go over some implementation options.

2. Problem Statement

Let’s imagine the following requirement. Within the controller class, both POST and PUT endpoints always need to have the same Content-Type.  Now, let’s see how we can share the same enum value in both endpoint definitions.

To better understand the problem statement, we’ll continue by exploring a demo use case.

3. Defining a Demo Use Case

To fulfill the requirement, we’ll need the following data structures.

A RequestContentType enum that looks like this:

enum RequestContentType {
    JSON, XML, HTML
}

Two custom annotations, @PutRequest and @PostRequest:

@interface PostRequest {
    RequestContentType type();
}

@interface PutRequest {
    RequestContentType type();
}

And finally, the following controller class:

class DataController {
    @PostRequest(contentType = RequestContentType.JSON)
    String createData() {
       // ...
    }
    @PutRequest(contentType = RequestContentType.JSON)
    public String updateData() {
        // ...
    }
}

As we can observe, the current controller implementation fulfills the requirement by referencing the JSON type two times for each function. Although this implementation fulfills the requirement, it is still not robust. Technically the @PostRequest can be easily initialized with a different contentType than the @PutRequest. 

In the next section, we’ll explore different approaches to achieving a strongly typed implementation that ensures that @PostRequest and @PutRequest always share the same contentType. We’ll define the ideal scenario, understand the Java language limitations, and finally explore the alternatives that we have.

4. Sharing the Same Enum Value

We want to ensure that by changing the RequestContentType in one central place, the change is reflected in all spots where the RequestContentType is referenced.

Next, we’ll look at what the usual way of thinking dictates to us.

4.1. Ideal Scenario

When we first think about this requirement, our mind flows in the following direction – let’s define a constant of type RequestContentType and then reference it in each annotation. Something that looks like this:

class DataController {
    static final RequestContentType REQUEST_TYPE = RequestContentType.JSON;
    @PostRequest(contentType = REQUEST_TYPE)
    String createData() {
        // ...
    }
    @PutRequest(contentType = REQUEST_TYPE)
    String updateData() {
        // ...
    }
}

This is the most straightforward and ideal implementation method. Unfortunately, it is not working as expected. This is because we face a compilation error stating, “Attribute value must be an enum constant”.

Next, let’s dig deeper to understand why this solution is not compiling and what constraints Java places on it.

4.2. Understanding the Java Constraints

As we can see in the JLS-9.7.1, in the case of annotations, if the element type is an enum, the only accepted value is an enum constant.  Following the same ubiquitous language of the Java Language specification, according to JLS-8.9.1, all enums, like JSON, XML, and HTML of the RequestContentType, are already constants. For more information about enums check a guide to Java Enums.

In conclusion, Java constrains us by design only directly to assign an enum to an annotation. So, the ideal scenario is not feasible.

5. Implementation Alternatives to Supply Enum as Constants to an Annotation

Now that we understand the limitations of the Java language let’s see how we can achieve the desired result. We’ll explore two options: simulating an enum by defining an interface with a set of integer constants and another using an enum with a nested static class inside. At the end, we’ll compare both approaches.

Next, let’s dive into both details and understand when to use one or the other.

5.1. Use an Enum Simulation With Integer Constants

Let’s start with the simulated enum, which looks like this:

interface SimulatedRequestContentType {
   static final int JSON = 1;
   static final int XML = 2;
   static final int HTML = 3;
}

Let’s also change the annotation definition like this to accept int types:

@interface PostRequest {
    int intContentType();
}
@interface PutRequest {
    int intContentType();
}

Finally, the usage would look something like this:

class DataController {
    static final int REQUEST_TYPE = SimulatedRequestContentType.JSON;
    @PostRequest(intContentType = REQUEST_TYPE)
    String createData() {
        // ...
    }
    @PutRequest(intContentType = REQUEST_TYPE)
    String updateData() {
        // ...
    }
}

As we see, this alternative solves the requirement but is no longer using enums.

Let’s see how we can still make use of enums.

5.2. Extend the Enum With a Nested Static Class for Constants

Now, let’s look at the option where we extend the initial enum with a nested static class to define the constants. The implementation of the enum ExtendedRequestContentType looks like this:

enum ExtendedRequestContentType {
    JSON(Constants.JSON_VALUE), XML(Constants.XML_VALUE), HTML(Constants.HTML_VALUE);
    ExtendedRequestContentType(String name) {
        if (!name.equals(this.name()))
        {
            throw new IllegalArgumentException();
        }
    }
    public static class Constants {
        public static final String JSON_VALUE = "JSON";
        public static final String XML_VALUE = "XML";
        public static final String HTML_VALUE = "HTML";
    }
}

The Constants class defines the values for each type. These will be used as parameter values of the annotations.

An important detail is the enum’s constructor that expects a string called name as a parameter. Basically, with this constructor, we ensure that whenever a new enum constant is defined, a constant with the same name will also be defined. Otherwise, an error while initializing the enum will be thrown. This will ensure a 1:1 mapping from the direction of the enum towards Constants.

Moreover, if we want to ensure a stricter bidirectional 1:1 mapping, we can write the following unit test:

@Test
public void testEnumAndConstantsSync() {
    Set<String> enumValues = getEnumNames();
    List<String> constantValues = getConstantValues();
    Set<String> uniqueConstantValues = constantValues.stream().distinct().collect(Collectors.toSet());
    assertEquals(constantValues.size(), uniqueConstantValues.size());
    assertEquals(enumValues, uniqueConstantValues);
}

In this unit test, we are first getting all the enum names as a Set. Then, using reflection, we get all the values of the public String constants. After, as a final step, we ensure that there are no constants with the same name and that there is an exactly 1:1 mapping between enums and constants.

Finally, let’s use the ExtendedRequestContentType:

class DataController {
    static final String EXTENDED_REQUEST_TYPE = ExtendedRequestContentType.Constants.XML_VALUE;
    @PostRequest(extendedContentType = EXTENDED_REQUEST_TYPE)
    String createData() {
        // ...
    }
    @PutRequest(extendedContentType = EXTENDED_REQUEST_TYPE)
    String updateData() {
        // ...
    }
}

5.3. Comparing the Alternatives

As we saw, both alternatives use data types other than enum to pass the value to the annotation. This is required to assign this value to another constant in the DataController class and share it between the annotations.

The main difference between the two is that in the option where we simulate an enum, we completely give up using enums, whereas, in the second option, we still keep using enums and ensure a 1:1 mapping to the defined constants.

The overhead of keeping enums and contents in sync makes total sense if we use enums and their functionality in other parts of the application. If we do so, then implementing a utility method to map from constant to enum value can be very useful:

static ExtendedRequestContentType toEnum(String constant) {
    return Arrays.stream(ExtendedRequestContentType.values())
      .filter(contentType -> contentType.name().equals(constant))
      .findFirst()
      .orElseThrow(IllegalArgumentException::new);
}

As a bottom line, if using enums is also required in other parts of the application, choose the second alternative; otherwise, exchange enums for constant values.

6. Conclusion

In this tutorial, we learned about Java’s limitations in supplying an enum value from a constant to an annotation and explored our alternatives. We started by looking at a use case where this requirement would be useful and then delving deeper into the language’s limitations. Finally, we implemented two different alternatives and explored their differences.

As always, the full implementation of this article can be found over on GitHub.

       

Learn how to work with Apache Commons projects.

       

1. Overview

MyBatis is a popular Java-based persistence framework that simplifies database operations by mapping SQL queries to Java methods.

When developing applications using MyBatis, it’s often useful for debugging to see which SQL queries are being used.

In this tutorial, we’ll explore how to log SQL queries to the console in MyBatis.

2. Supported Logging Implementations

Before delving into SQL logging in MyBatis, it’s important to understand the supported logging implementations.

MyBatis is a flexible framework that can integrate with various logging frameworks, including SLF4J, Apache Commons Logging, Log4j 2, and JDK Logging. This article will explore two different logging options: stdout logging and SLF4J.

Stdout logging is beneficial during local feature development as it provides a simple approach for debugging. On the other hand, SLF4J is better suited for production applications, offering versatile abstractions that seamlessly integrate with users’ preferred logging frameworks during deployment.

3. Configuring Stdout Logging in MyBatis

Logging MyBatis SQL using stdout allows us to view the executed SQL statements directly on the console. This method is handy during development and debugging.

To enable stdout logging for MyBatis SQL, we need to add a logging setting in the mybatis-config file of our application:

<configuration>
    <settings>
        <setting name="logImpl" value="STDOUT_LOGGING"/>
    </settings>
</configuration>

After configuring the logImpl property to STDOUT_LOGGING, MyBatis will output the raw SQL statements, query parameters, and query results when executing SQL queries. The output typically includes detailed information such as the executed SQL, bound parameters, and the returned result set:

==>  Preparing: SELECT addressId, streetAddress FROM Address WHERE addressId = ? 
==> Parameters: 1(Integer)
<==    Columns: ADDRESSID, STREETADDRESS
<==        Row: 1, 123 Main Street

The output indicates preparing a SQL query to fetch data from the Address table using a specific ID. It shows the parameters, the result set columns (ADDRESSID and STREETADDRESS), and an illustrative row of data (ADDRESSID: 1, STREETADDRESS: 123 Main Street). Additionally, it tells us that the total count of returned rows was 1.

Apart from configuring the logImpl property in mybatis-config, we also have the option to set the log implementation programmatically. We can achieve this by calling the static method LogFactory.useStdOutLogging() before calling any other MyBatis method.

Using stdout logging has a downside in that it lacks fine-grained control over the logs. With stdout logging, MyBatis logs all executed SQL queries in detail, which can be overwhelming and make it difficult to focus on the essential information.

To achieve more precise control over logging, such as determining which part or mapper prints the logs, it’s recommended to use a logging framework.

4. Configuring SLF4J and Logback Logging in MyBatis

4.1. Setting Up SLF4J and Logback Logging

First, we need to add the SLF4J and Logback dependencies to our project’s build file. Since Logback automatically includes SLF4J as a transitive dependency, for Maven projects, we only need to specify the Logback dependency in the pom.xml file:

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.4.14</version>
</dependency>

Next, we need to create a Logback configuration file, typically named logback.xml, to define the logging behavior:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration>
<configuration>
    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%5level [%thread] - %msg%n</pattern>
        </encoder>
    </appender>
    <root level="INFO">
        <appender-ref ref="stdout"/>
    </root>
</configuration>

This configuration creates a root logger to log messages with a log level of INFO or higher and directs them to the stdout appender for output to the console.

Following that, similarly to the stdout logging configuration, we need to set the logImpl property to SLF4J in the mybatis-config file:

<configuration>
    <settings>
        <setting name="logImpl" value="SLF4J" />
    </settings>
</configuration>

4.2. Logging Mapper

By configuring the logging as mentioned above, logging the mapper becomes straightforward. We can set the logger name to the fully-qualified name of the mapper interface, or the namespace if an XML mapper file is used:

<logger name="com.baeldung.mybatis.mapper.AddressMapper" level="TRACE"/>

This allows easy logging control by associating the logger with the desired mapper. Only queries related to this mapper will have trace-level logging applied.

4.3. Logging a Specific Mapper Method

To selectively log the execution of a specific method, such as getFruitById in the FruitMapper, we can configure the logger accordingly:

<logger name="com.baeldung.mybatis.mapper.AddressMapper.getAddresses" level="TRACE"/>

With this configuration, the logger will only print the log to the console when executing the getFruitById method, allowing for more focused and granular logging control.

4.4. Logging Mappers in a Package

We can easily enable logging for all mappers under a specific package by setting the logger name to the package name:

<logger name="com.baeldung.mybatis.mapper" level="TRACE"/>

This approach allows for comprehensive logging across all mappers within the designated package.

4.5. Logging SQL Statements Only

In scenarios where queries can produce large result sets, we may prefer to view the SQL statements without logging the actual results. MyBatis is designed to log SQL statements at the DEBUG level, while it logs results at the TRACE level. If we wish to see the statement without the result, we need to set the logging level to DEBUG:

<logger name="com.baeldung.mybatis.mapper.AddressMapper" level="DEBUG"/>

5. Configuring SQL Logging in MyBatis With Spring Boot

Spring is a widely adopted framework, and in many cases, MyBatis is configured in conjunction with Spring instead of for standalone usage. When working with Spring Boot, there’s little to do to configure MyBatis SQL logging. Spring Boot utilizes logback as its default logging implementation, and MyBatis’ logging mechanism prioritizes SLF4J.

Therefore, to enable MyBatis SQL logging for a specific mapper, we add properties to our Spring Boot application.properties file:

logging.level.com.baeldung.mybatis.spring.ArticleMapper=DEBUG

By configuring the log level to DEBUG for the designated mapper, we’ll have detailed SQL logging for that particular mapper.

6. Conclusion

In this article, we looked at the configuration of SQL logging in MyBatis, including stdout logging, SLF4J with Logback, logging specific mappers/methods/packages, and integration with Spring Boot.