Differences Between Paths.get and Path.of

Last updated: January 8, 2024

Written by: baeldung

Reviewed by: David Martinez

Java IO

Java NIO

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

1. Overview

In this article, we’ll comment on the similarities and differences between the methods Paths.get() and Path.of().

2. Identical Behavior

The Path.of() method takes a URI as an argument and converts it into the Path of the associated object.

Let’s now have a look at the code of Paths.get():

public final class Paths {
    public static Path get(URI uri) {
        return Path.of(uri);
    }
}

As we can see, the only thing Paths.get() does is call Path.of(). Therefore, the two methods return an identical result.

3. The Differences Between the Methods

We’ll now comment on the difference between those two methods.

3.1. Introduction Version

Before Java 8, it was not possible to define a default static method inside an interface. Hence Path needed a companion interface, Paths. All the factory methods were defined in Paths at this time.

Then this limitation was removed, and in Java 11, the code of the factory method has eventually been moved to the Path interface. Additionally, the code of Paths.get() was updated to defer to Path.of(). Paths.get() was indeed kept to ensure backward compatibility.

3.2. Naming Pattern

The code was not only moved, but the name of the factory method did also change. The problem with the original name is that it looks like a getter. However, Paths.get() doesn’t get anything that belongs to the Paths object. The standard name for static factory methods in Java is of. For instance, EnumSet.of() follows this pattern. As a consequence, the new method was called Path.of() for consistency purposes.

4. Which One Should We Use?

If we’re working with a version between Java 7 and 10, we have no other choice but to use Paths.get(). Otherwise, if we’re working with a later version, we should go for Path.of(). The Paths class may indeed be deprecated in a future Java release, as it’s stated in the class’ comments. Moreover, using directly the factory method from Path spares an additional input.

5. Conclusion

In this tutorial, we’ve understood that the two identical methods, Paths.get() and Path.of(), coexist for some historical reasons. We’ve analyzed their differences and concluded with the most suitable fit for us depending on our situation.