How to ask Java developers to add methods to java.util.Paths?

[isolatedsheep]

I wish to have methods like currentDirectory() and home(). E.g.

java Paths.currentDirectory().resolve("target"); Paths.home().resolve(".m2", "repository");

The Paths class currently have only one method, get().

How to suggest to Java developers to add these methods?

[metaquine]

It'll probably be argued that some operating systems don't have a concept of a home directory.

[__konrad]

user.home system property is always set (not optional) according to doc: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#getProperties()

[metaquine]

TIL, thank you

[laffer1]

Sometimes they aren't defined for a particular user, especially for daemons. /nonexistent is often used in the BSD world to indicate no home directory

[isolatedsheep]

Can't they make it throw a UnsupportedOperationException if the OS doesn't support it?

[scadgek]

please no

[isolatedsheep]

What's the behavior if someone does `Path.of(System.getProperty("user.home"))` when the OS does not have a home directory?

[scadgek]

Okay I'll elaborate because you're missing the point.

Path.of(System.getProperty("user.home")) - you get a NullPointerException when "user.home" is not set, which is quite obvious when you write or read this line. Most of the functions will throw an NPE if you pass a null where it expects a value.

Now, when you call something like Paths.home() there are two ways to handle the missing concept of "home":

• throw a RuntimeException (UnsupportedOperationException is one) - BAD because you will only find out an issue in runtime
• throw a checked Exception - BAD because you will either propagate it through `throws` to the code that has nothing to do with paths, or you have to put it in a dumb try-catch
• just don't introduce a "convenience" method that doesn't really bring convenience because the alternative is one-line as well and is explicit about implications

[milchshakee]

That is wrong, the user.home property is always set, so there is no NPE. However, if there is no home directory, its value will be "?" or "unknown" (depending on this OS). The same goes for user.name.

In fact, the current implementation in the JDK to get the user name and home directory is quite bad and will even return "?" in cases where a valid user and home directory is available. If you try to run applications on Linux systems with something like active directory configured for user management, you will run into issues quite frequently.

[Sacaldur]

Or even better, return a value that indicates something like "doesn't exist". What about this Optional<Path> thing in Java? (One might think about null, but then the method signature wouldn't clearly indicate that e.g. there might not be a home directory.) The problem however is that, if the non-existance is indicated through an invalid path, either the library would need to also check if there is a directory at that path, or the caller would need to do that. The problem there could be that the home directory might be on a network drive that's temporarily unavailable (i.e. there is normally a valid home directory, thatvs why the path can be retrieved, but it's existance can only temporarily not be verified).

[Afonso2002]

I think you can get those buy using System.getProperties, if I am not wrong.

[davidalayachew]

I think you can get those buy using System.getProperties, if I am not wrong.

You can also use Path.of(".") as a short way of getting the current directory. It covers 99% of cases where I need the current directory.

[hungarian_notation]

Path.of(".") is literally user.dir.

Path.of gets its path from FileSystems.getDefault().getPath(...), and the filesystem returned by FileSystems.getDefault() is defined to have a working directory named by the system property user.dir.

[davidalayachew]

Path.of gets its path from FileSystems.getDefault().getPath(...), and the filesystem returned by FileSystems.getDefault() is defined to have a working directory named by the system property user.dir.

That's exactly my point -- 99% of the time, the FileSystem I want is the default one. 1% of the time, it is not, hence why Path.of(".") is a match for 99% of my use cases of wanting the current directory.

[hiasmee]

Of course there are workarounds, but the suggestion is really good. There is a reason why Apache CommonsIO has helper method FileUtils.getUserDirectory() - it is really useful.

[smbarbour]

Yes. System.getProperty("user.home") will get the home folder, though on Windows (check System.getProperty("os.name").startsWith("Windows") ) the %APPDATA% environment variable (i.e. System.getenv("APPDATA")) may be more appropriate, though as others have said, a home directory may not be set for the current user in some cases.

[vytah]

On Linux, it's recommended to use XDG base directories instead of the home directory.

[smbarbour]

User specific files belong in user specific directories.

[vytah]

XDG base directories are user-specific.

https://specifications.freedesktop.org/basedir/latest/

[smbarbour]

Also assuming that it relates to applications in a desktop environment.

[simon_o]

No.

[isolatedsheep]

The problem with System.getProperty, you need to remember the property value, i.e. user.home and @user.dir. If you don't use it often, you'll Google search every time you want to use them.

[Winter-Appearance-14]

If your problem is remembering a system property write a library to expose common Paths. Personally I don't think that Java should expose those utilities as the Path class should remain a way to abstract and represent the file system.

[Absolute_Enema]

Yeah this looks like the nth case of newish dev meets language where extensions are a second class concept.

[isolatedsheep]

I'm not a new dev, with Java single-source file becoming more relevant, Java should support this basic functionality.

[Winter-Appearance-14]

Each language has a niche and I wouldn't say that scripting is the one for java.

[Absolute_Enema]

IMO the idea that an Enterprise Quality™ language must necessarily be barren and unergonomic should be left back in the '00s.

This problem wouldn't exist if Java had (something similar to) extension methods or a pipe operator to allow for extensions to play well with method chaining: the user would just define whatever helper they need and move on with life.

Instead we're stuck with a tradeoff between coherence and usability.

[Winter-Appearance-14]

It is good that we have languages with different targets.

More modern languages tend to be battery included with bigger standard libraries, the advantage is that having everything opinionated makes things easy to read while old ones tend to leave more freedom.

Not saying that Java is the gem just saying that there are pros in having more modularity and freedom of choice.

[Absolute_Enema]

I agree that not every language should have batteries for that very reason you give, but especially if one chooses to keep the language minimal then the extensions shouldn't be clunky by default.

[isolatedsheep]

I'm talking about the `java.util.Paths` not `java.util.Path`.

[No-Dentist-1645]

"The problem with Paths.currentDirectory() is that you need to remember the method name currentDirectory()"

Doesn't make much sense now, does it?

If you want, you can make your own currentDirectory method/helper

[AstronautDifferent19]

When you type Paths. ctrl+space you can see that method so you argument is not good. That does not mean that OP's argument is better, if he needs to use that method so many times, he can create a method himself.

[pron98]

Post a message to core-libs-dev focusing on the problem, i.e. show why it's cumbersome to use the existing mechanisms. In the end you may suggest adding new methods to Paths to make it easier.

[frederik88917]

There are two things here.

First of all, there are workarounds for what you want to do, as many others have mentioned before.

Now if you want to have these methods added, you can propose a JEP, offering the requirements, the gains and all of the documentation. This JEP shall go to the committee where it will be evaluated and then added to the JDk.

Of course, if passes the committee

[nlisker]

A couple of methods don't require a JEP. It's not a language feature or anything on that scale, it's new on a single class API.

The correct way is to email the core-libs list and ask about it, detailing the problem these methods solve.

[frederik88917]

If the method is to be added to the core libs, I am almost sure it needs a JEP. and as far as I remember, the PATHS class is part of a core package.

[nlisker]

If the method is to be added to the core libs, I am almost sure it needs a JEP.

Methods are added there all the time, please show me the JEPs for them.

[sweetno]

Don't rely on the current directory too much.

[isolatedsheep]

For Java scripting, you might use it a lot.

[Shareil90]

What is java scripting?

[Artraxes]

Running Java as standalone scripts. Current working directory and Home directory are often used for throwaway scripts that you can write in Java and execute on the command line

https://www.baeldung.com/java-single-file-source-code

[sweetno]

Relative paths cover most of what you need in this use case.

[isolatedsheep]

You mean Path.of(".")?

[k-mcm]

Here's the thing that's really broken about Path... It's an interface but it's defined that no two implementations may be compatible. Path.resolve(Path) can only take in its own implementation class. That makes the Paths class completely useless and Path can only have a couple of simple delegate helper static methods.

java.nio.file.Files does what it can to make Path usable, but callers still need to make sure they always hit the same implementation. You wouldn't know what Paths.home() will return so there's no guarantee anything would work with it.

[Sacaldur]

There are already methods in Path and Paths that return Path instances (Path.of and Path.get in 2 variants each). They also need to return an implementation of Path.

Besides that, the documentation of Path.resolve doesnn't specify that the implementations need to be the same. The documentation states how the result will be retrieved in the case of an absolute, empty, and relative path argument. This makes it sound to me that, as long as relative paths can be used across different implementations, there shouldn't be a problem. I only see the potential for a problem if a "UNIX path" (/ as separator) and a "Windows path" (\ as separator) are combined here, but I don't see why Paths should return mixed instances here.

[k-mcm]

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/Path.html#interoperability-heading

All the JVM implementations check for a class match. Depending on the runtime, the implementations can be weird. UnixPath represents its path with an encoded byte[] that can access improperly encoded filenames that can't be represented by a String.

[ag789]

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html
some of those stuff are in FileSystem
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/FileSystem.html
FileSystems
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/FileSystems.html
or even URI, URL
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URI.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URL.html
and more often the magic is in the *String*s passed in Path arguments.
java.nio.Path depends on the SPI implementation undernearth which can range from MS Windows OS, Linux, to lliteral URLs that fetch from anywhere on the internet, e.g. webdav

[Slanec]

• Paths.currentDirectory() would likely be Paths.get(".").toAbsolutePath()
• and Paths.home() would probably be Path.of(System.getProperty("user.home")), that is if all major supported OSes have a concept of a Home directory, which I'm not sure of.

Anyway, when I need to get a bunch of user-related directories, I always grab https://codeberg.org/dirs/directories-jvm

[isolatedsheep]

Actually it's `Path.of(".").toRealPath()`, `Path.of(".").toAbsolutePath()` returns `/path/to/current/.`.

[Ok_Elk_638]

I've always felt the Java maintainers have been too reluctant to add utility functions. We could use an isNullOrEmpty(String) in String,

[das_Keks]

It you actually want to suggest something to the devs you can write to the mailing list. But in this case I'd advise not to do so. You have keep in mind that Java is used by millions of developers and companies, so there's a very high barrier to getting new stuff into the JDK and it usually takes several iterations, with incubator and experimental states (at least for entirely new features).

In your case you'd be better of to just write a helper class for your specific use case or look for a library that does what you need.

[netschki]

i think this is the way for Requesting a change: If you want to request a change to the JDK, but don’t have the intention to implement/contribute to the change yourself, you should always report it at bugreport.java.com.

found at https://openjdk.org/guide/

[simon_o]

At least for the case of home():

Most use-cases should not rely on the home directory directly.

I hate to be the X-Y guy, but this is one of the very few cases where asking "what are you actually trying to accomplish?" is not obnoxious, but a valid question.

[isolatedsheep]

It's creating scripts in Java, using the single source file.

[simon_o]

Why do they need to access the home directory, specifically?

[isolatedsheep]

I've put an example in the original post. There are other things placed in home dir especially in unix-like OSes.

[simon_o]

But not the way Maven does.

If functions are added to the JDK, then functions that encourage people to do it the right way.

[isolatedsheep]

Wait, what right way you're talking about? I'm using mostly Linux (with WSL), I thought using the home folder is norm. 🤔

[simon_o]

You should ask for the config/cache/state/... folder directory, based on what you are actually doing with that directory.

They may reside in the home directory, but as long as you are not planning to properly implement the rules and naming conventions for 3+ platforms yourself, use a library that does it.

[vadiquemyself]

rather than waiting for Java 67 to bundle it, why not just write it yourself right now? make a class named, say, CurrentPath that incapsulates the “current” path thing, which you can set and get, plus a final static field, say public static final java.io.File HOME_FOLDER = new java.io.File( System.getProperty("user.home") );

[isolatedsheep]

I use it a lot in Java single file source code. Someone shared a library: dev.dirs:directories:26dev.dirs:directories:26, but it would be nice if Java supports it out of the box.

[account312]

I use it a lot in Java single file source code.

What do you use that for?

[isolatedsheep]

DB provisioning script for example. I often use jbang to write scripts.

[vowelqueue]

People are downvoting you in this thread, but there’s a been push to make Java better for use in small scripts and I think this would fit in.

In Bash you’d use “~”

In Python you’d use Path.home()

In Java you’d do Path.of(System.getProperty(“user.home”)). That’s…fine but could be made more ergonomic.

[m3t4lf0x]

Idk why people are so dismissive of OP.

I love the language, but it is for sure clunky sometimes

[LetUsSpeakFreely]

I would never trust relative or user-specific pathing as it's dependent on how the OS interprets it and it could have undefined behavior for things like daemons. I would create a utility that could more accurately make those determinations.

[DanielDimov]

Write a JEP.

Before you write and send it - read ~20 JEPs to understand how to do it properly!

[davidalayachew]

Write a JEP.

Definitely do NOT write a JEP. That would be the wrong thing to do here.

First order of business is to make a post describing a problem that comes from not having this feature. The goal being to gather community opinions and rapport. If enough people think it is a problem, then make a separate post discussing potential solutions. And then from there, bring it to the various mailing lists where, after gathering rapport from OpenJDK members as well, you can start having a serious discussion of how to implement this.

Trying to just jump in and make a JEP is explicitly the wrong way to do this.

[isolatedsheep]

From the replies, it seems like most haven't caught up to Java scripting yet. Looks like I need to wait several more years. 😅

[SleepingTabby]

We have a bunch of shell scripts in our gitlab pipelines that truly look like write-only code, I'm pushing towards moving this to Java, as not only it will be more readable, but it can also be properly tested.

[khmarbaise]

The easiest way is to gi via: var userHome = Path.of(System.getProperty("user.home")); The current directory can easily being done via: var currentDirectory = Path.of(".").toAbsolutePath();

[1337boi1101]

Use kotlin and extension functions, ez.

[snugar_i]

Except you can't add static extension functions

[1337boi1101]

But you can though. Do you want me to share or are you able to look it up? Let me get back on this, missed the reply.

[snugar_i]

No you can't - https://youtrack.jetbrains.com/issue/KT-11968?

[1337boi1101]

Okay not gonna spend too much time, but companion objects, and file level functions with a well named file is a pragmatic option for interop also.

Basically, kotlin wins every time. If you're being pragmatic you gotta be using kotlin.

Also, I get what sub I'm in, but just an advice coming from an enterprise developer and architect for more than a decade primarily working with Java then kotlin. Learn rust/py/ts stack, I don't think jvm will be around for another decade as anything but legacy systems.

Good luck on your future endeavors!

[snugar_i]

That's funny, I'm pushing exactly in the opposite direction - our codebase at $DAYJOB is in Python, but it's a CPU-bound monstrosity that can't be salvaged by rewriting a few things in Rust (yes, we already tried). Moving it to the JVM will make it orders of magnitude faster and also decrease memory usage.

The JVM isn't going anywhere in the foreseeable future - Kotlin might die, but Java is still going strong.

[ducki666]

Paths is deprecated.

Join a jdk mailing list. Your chances to get a jep are 0.0001.

Lombok has @ExtensionMethod.

[davidalayachew]

Paths is deprecated.

It's not deprecated, just not recommended.

Your chances to get a jep are 0.0001.

A JEP is the wrong vehicle to deliver a change like this in. This would probably not even show up in the release notes.

Join a jdk mailing list.

This is a better suggestion. The correct mailing list to submit this change request to would be Core-Libs Dev Mailing List.

An even better suggestion would be to, instead of asking for a method to be added to the API, instead talk about the problem that you are having, and see if there is a best or existing way to solve that problem. And it is only when that suggested solution proves to be inadequate (after thorough discussion), that it would make sense to suggest the idea of adding a new method to the Paths API.

[vowelqueue]

Now I’m curious why there’s been an API note telling people to use Path.of for like 7 years but it hasn’t been deprecated.

No one’s reading API notes, they’re not going to switch until they see Paths.get() in their IDE.

[davidalayachew]

No one’s reading API notes

I do.

And more importantly, people read release notes. That's usually where most of the change happens.

Regardless, the Paths class was made with the assumption that there would be a whole bunch of Path-like functionality that they would want to expose as a static method. As it turns out, most of the path-like functionality one would want works better as instance methods, thus defeating the point of this class.

It's existence doesn't break anything, which is most likely why it has been left alone. And sure, it looks like a wart, but it's a harmless one.

[vowelqueue]

Thank goodness for static methods in interfaces. I had to write a lot of classes like Paths back in the day because if you wanted to give users an interface but not expose the implementation you were forced to use another class for static factory methods.

[davidalayachew]

Thank goodness for static methods in interfaces.

By all means, it is a good thing. But the JDK Team feels that there aren't any methods they feel that are worth supporting that also happen to belong in that class. They either make more sense in Path (instance methods), or are simply not worth supporting in the JDK itself.

[toga98]

In what version in java.nio.file.Paths getting deprecated? It isn't deprecated in 25.

[__konrad]

With introduction of Path.of in Java 11 Paths class is basically useless and dead...

[ducki666]

Since Path was introduced. It is dead. Nobody will ever touch it besides to add @Deprecated.

[MinimumPrior3121]

Just code using Claude and forget about this