How to recursively rename files with a specific suffix in Java?

The following code snippet show you how to recursively rename files with a specific suffix. In this example we are renaming a collection of resource bundles files which ends with _in.properties into _id.properties. The code snippet also count the number of files affected by the process. We use the Files.move() method to rename the file, if you want to copy the files instead of renaming them, then you can use the Files.copy() method.

Here is the complete code snippet:

package org.kodejava.io;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.stream.Stream;

public class RenameResourceBundles {
    public static void main(String[] args) {
        String startDirectory = "C:/Users/wayan/Projects/Lpdp/Jetty-12-Locale";
        AtomicInteger counter = new AtomicInteger(0);

        try (Stream<Path> paths = Files.walk(Paths.get(startDirectory))) {
            paths.filter(Files::isRegularFile)
                    .filter(path -> path.toString().endsWith("_in.properties"))
                    .forEach(path -> renameFile(path, counter));
        } catch (IOException e) {
            e.printStackTrace();
        }

        System.out.println("Total files renamed: " + counter.get());
    }

    private static void renameFile(Path path, AtomicInteger counter) {
        try {
            String newName = path.toString().replace("_in.properties", "_id.properties");
            Path newPath = Paths.get(newName);
            Files.move(path, newPath);
            System.out.println("Renamed: " + path + " to " + newPath);
            counter.incrementAndGet();
        } catch (IOException e) {
            System.out.println("Failed to rename: " + path);
            e.printStackTrace();
        }
    }
}

This code will recursively search through all subdirectories starting from the specified root directory and rename any files that end with _in.properties to _id.properties. The process prints the renamed file, and finally outputs the total number of files that were successfully renamed after traversing the directory tree.

The explanation of the code snippet above:

  • The Files.walk method is used to traverse the directory tree starting from the given directory.
  • The filter method is used to select only regular files that end with _in.properties.
  • The renameFile method handles the renaming of each file, replacing _in.properties with _id.properties.
  • An AtomicInteger named counter keeps track of the number of files renamed. AtomicInteger is used to handle the count in a thread-safe manner, which is useful if the code is ever modified to use parallel streams or multi-threading.
  • Inside the renameFile method, counter.incrementAndGet() is called each time a file is successfully renamed. This increments the counter by one.
  • After the Files.walk operation, the total number of renamed files is printed using System.out.println("Total files renamed: " + counter.get());.

How to copy files ending with a specific string to another file in Linux/macOS?

In Java 17, the Locale for Indonesia changed from in_ID to id_ID. In my project, the resource bundle files are named with the suffix _in.properties which is unrecognized by Java 17. To resolve this issue, I need to create copies of these resource bundle files that ends with _id.properties.

Here are solutions for both Linux/macOS (using Bash).

#!/bin/bash

# Set the root directory for the search
ROOT_DIR="/path/to/root_directory"

# Find all files ending with '_in.properties' and process each one
find "$ROOT_DIR" -type f -name "*_in.properties" | while read -r FILE; do
    # Construct the new file name by replacing '_in.properties' with '_id.properties'
    NEW_FILE="${FILE%_in.properties}_id.properties"
    # Copy the original file to the new file
    cp "$FILE" "$NEW_FILE"
done

Save this script as copy_properties.sh, make it executable with chmod +x copy_properties.sh, and run it with ./copy_properties.sh.

Explanation

  • find "$ROOT_DIR" -type f -name "*_in.properties": Finds all files ending with _in.properties.
  • while read -r FILE; do ... done: Loops through each found file.
  • ${FILE%_in.properties}_id.properties: Constructs the new file name by replacing _in.properties with _id.properties.
  • cp "$FILE" "$NEW_FILE": Copies the original file to the new file.

These scripts will recursively search the specified directory for files ending with _in.properties, then create a copy of each file with _id.properties in the same directory.

What are the benefits of using parameterized log messages?

When creating a program in Java, we are mostly, if not always, add logging mechanism in our program. This log can be use to add debug information to our program, which can help us when problem occurs in our program. We usually add log message to the start of our methods to show the value of input parameters, or at the end of the methods before exiting to show the process results. We also add log information in the catch block of the try-catch statement to log messages related to exception that occurs in our program.

Here’s an example to illustrate the difference:

Concatenation approach:

logger.info("User " + username + " logged in at " + loginTime);

Parameterized approach:

logger.info("User {} logged in at {}", username, loginTime);

In Java, using parameterized log messages instead of concatenation offers several benefits:

Performance

Parameterized log messages can improve performance compared to string concatenation. When you concatenate strings, the JVM creates a new string object each time, which can lead to unnecessary memory allocation and garbage collection overhead. Parameterized messages, on the other hand, only evaluate the placeholders when the log message is actually logged, which can reduce memory usage and improve performance.

Readability

Parameterized log messages often result in cleaner and more readable code. By separating the log message template from the actual values, it’s easier to understand the intent of the log message and identify the dynamic values being logged.

Internationalization (i18n) and Localization (l10n)

Parameterized log messages make it easier to support internationalization and localization efforts. Since the placeholders in the log message template remain the same regardless of the language, translators can focus solely on translating the template and not worry about the dynamic values.

Prevention of unnecessary string manipulation

When concatenating strings for log messages, you may inadvertently perform unnecessary string manipulation operations (e.g., converting non-string values to strings). With parameterized messages, these operations are only performed if the log message is actually logged, reducing unnecessary computation.

Avoidance of potential formatting issues

When concatenating strings, you may encounter formatting issues, especially if the dynamic values contain special characters or formatting codes. Parameterized messages handle formatting automatically, ensuring that the logged values are properly formatted according to their data types.

Overall, using parameterized log messages can lead to more efficient, readable, and maintainable code in Java logging practices.

Below is another ilustration of adding log messages in our program:

package org.kodejava.util.logging;

import java.util.logging.Level;
import java.util.logging.Logger;

public class ExampleLogger {

    private static final Logger logger = Logger.getLogger(ExampleLogger.class.getName());

    public void performLogin(String username, String loginTime) {
        // Simulate login process
        boolean loginSuccessful = true; // Assume login is successful for demonstration

        if (loginSuccessful) {
            // Log successful login using parameterized message
            logger.log(Level.INFO, "User {0} logged in at {1}", new Object[]{username, loginTime});
        } else {
            // Log failed login using parameterized message
            logger.log(Level.WARNING, "Failed login attempt for user {0} at {1}", new Object[]{username, loginTime});
        }
    }

    public static void main(String[] args) {
        ExampleLogger exampleLogger = new ExampleLogger();
        exampleLogger.performLogin("john_doe", "2024-06-08 10:00:00");
    }
}

In this example:

  • We define a performLogin method that simulates a user login process. The method takes username and loginTime as parameters.
  • Inside the method, we set a boolean variable loginSuccessful to true for demonstration purposes (assuming the login is successful).
  • We then use the java.util.logging.Logger class to log the login event. We use parameterized log messages with placeholders {0} and {1} for username and loginTime, respectively.
  • Depending on whether the login is successful or not, we log the event at different levels (INFO for successful login and WARNING for failed login).
  • In the main method, we create an instance of ExampleLogger and call the performLogin method with sample values for username and loginTime.

This example demonstrates the usage of parameterized log messages in a complete method for logging login events in Java.

How do I determine if a date falls between two dates?

Java provides different ways to determine if a certain date falls within a specified range. In this article, we’ll look at examples using the old java.util.Date and java.util.Calendar classes, as well as the newer Java Date Time API.

Using java.util.Date and java.util.Calendar

Before Java 8, you’d have to use Date or Calendar to work with dates:

package org.kodejava.datetime;

import java.util.Calendar;

public class CheckDateRange {
    public static void main(String[] args) {
        Calendar start = Calendar.getInstance();
        start.set(2024, Calendar.JANUARY, 1);
        Calendar end = Calendar.getInstance();
        end.set(2024, Calendar.DECEMBER, 31);
        Calendar target = Calendar.getInstance();
        target.set(2024, Calendar.JUNE, 15);

        if ((target.after(start) || target.equals(start)) &&
            (target.before(end) || target.equals(end))) {
            System.out.println("The date is within the range.");
        } else {
            System.out.println("The date is not within the range.");
        }
    }
}

The disadvantage with this approach is the excessive verbosity and error-prone copy-pasting necessary for setting up the Calendar instances.

The Java 8 Way – Using java.time.LocalDate

Java 8 introduced the new Java Date Time API, which replaced the inconsistent Date and Calendar classes with the more intuitive LocalDate, LocalTime, LocalDateTime, and ZonedDateTime. Here’s the same task performed using LocalDate:

package org.kodejava.datetime;

import java.time.LocalDate;

public class AnotherCheckDateRange {
    public static void main(String[] args) {
        LocalDate startDate = LocalDate.of(2024, 1, 1);
        LocalDate endDate = LocalDate.of(2024, 12, 31);
        LocalDate targetDate = LocalDate.of(2024, 6, 15);

        if ((!targetDate.isBefore(startDate)) && (!targetDate.isAfter(endDate))) {
            System.out.println("The date is within the range.");
        } else {
            System.out.println("The date is not within the range.");
        }
    }
}

In this code, startDate and endDate define the range of dates. The targetDate is the date you want to check.

The isBefore() method returns true if the targetDate is before the startDate, and the isAfter() method returns true if the targetDate is after the endDate. So, if targetDate is not before the startDate and not after the endDate, it means that the targetDate is between startDate and endDate (inclusive). If the targetDate is exactly the same as startDate or endDate, this condition will also return true.

This simplified API requires significantly less code and eliminates a number of potential bugs and inconsistencies.

Conclusion

The older java.util.Date and java.util.Calendar facilities for working with dates are widely considered difficult to use and error-prone. While they work for simple tasks, the newer Java Date Time API is recommended for all new applications due to its simplicity, consistency, and flexibility. It aligns with ISO standards and covers a comprehensive range of use-cases needed for date-time calculations. Migrating from older APIs to Java 8 Date Time API is likely advantageous for most projects.

How do I create a servlet filter to make secure cookies?

The CookieFilter class in this example is a servlet filter. Servlet filters in Java web applications are used to perform tasks such as request/response modification, authentication, logging, and more. In the context of managing cookies, a CookieFilter can be used to intercept requests and responses to handle cookie-related operations, such as setting secure attributes on cookies or checking cookie values for authentication purposes.

Here’s an example of how you can implement a CookieFilter class in Java:

package org.kodejava.filter;

import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;

@WebFilter("/*")
public class CookieFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // Initialization code, if needed
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
            throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        // Check if a session exists
        HttpSession session = httpRequest.getSession(false);
        if (session != null) {
            // Example: Set secure attribute on session cookie
            sessionCookieSecure(httpRequest, httpResponse);
        }

        // Continue the request chain
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
        // Cleanup code, if needed
    }

    private void sessionCookieSecure(HttpServletRequest request, HttpServletResponse response) {
        // Assuming the session cookie name
        String cookieName = "JSESSIONID"; 
        Cookie[] cookies = request.getCookies();
        if (cookies != null) {
            for (Cookie cookie : cookies) {
                if (cookie.getName().equals(cookieName)) {
                    // Set the secure attribute on the session cookie
                    cookie.setSecure(true);
                    // Update the cookie in the response
                    response.addCookie(cookie); 
                    break;
                }
            }
        }
    }
}

In this example:

  • The CookieFilter class implements the Filter interface, which requires implementing methods like init, doFilter, and destroy.
  • Inside the doFilter method, it checks if a session exists for the incoming request.
  • If a session exists, it calls the sessionCookieSecure method to set the secure attribute on the session cookie.
  • The sessionCookieSecure method iterates through cookies in the request, finds the session cookie (e.g., JSESSIONID), and sets its secure attribute to true.

You can modify this filter implementation based on your specific cookie management requirements, such as setting secure attributes on specific cookies or performing additional cookie-related tasks.