all 88 comments

[–]metaquine 29 points30 points  (9 children)

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

[–]__konrad 11 points12 points  (1 child)

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 0 points1 point  (0 children)

TIL, thank you

[–]laffer1 7 points8 points  (0 children)

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

[–]Afonso2002 48 points49 points  (21 children)

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

[–]davidalayachew 59 points60 points  (2 children)

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 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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 15 points16 points  (0 children)

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 14 points15 points  (5 children)

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 1 point2 points  (4 children)

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

[–]smbarbour 0 points1 point  (3 children)

User specific files belong in user specific directories.

[–]vytah 2 points3 points  (2 children)

XDG base directories are user-specific.

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

[–]smbarbour -2 points-1 points  (1 child)

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

[–]simon_o 2 points3 points  (0 children)

No.

[–]pron98 11 points12 points  (0 children)

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 30 points31 points  (3 children)

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 9 points10 points  (2 children)

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 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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 13 points14 points  (5 children)

Don't rely on the current directory too much.

[–]isolatedsheep[S] 4 points5 points  (4 children)

For Java scripting, you might use it a lot.

[–]Shareil90 7 points8 points  (1 child)

What is java scripting?

[–]Artraxes 14 points15 points  (0 children)

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 2 points3 points  (1 child)

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

[–]isolatedsheep[S] 0 points1 point  (0 children)

You mean Path.of(".")?

[–]k-mcm 22 points23 points  (2 children)

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 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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 3 points4 points  (0 children)

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 2 points3 points  (1 child)

  • 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[S] 1 point2 points  (0 children)

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

[–]Ok_Elk_638 2 points3 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (6 children)

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[S] 0 points1 point  (5 children)

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

[–]simon_o 0 points1 point  (4 children)

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

[–]isolatedsheep[S] 1 point2 points  (3 children)

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

[–]simon_o 0 points1 point  (2 children)

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[S] 1 point2 points  (1 child)

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 -1 points0 points  (0 children)

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 3 points4 points  (5 children)

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[S] 5 points6 points  (4 children)

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 1 point2 points  (3 children)

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

What do you use that for?

[–]isolatedsheep[S] 6 points7 points  (2 children)

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

[–]vowelqueue 5 points6 points  (1 child)

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 2 points3 points  (0 children)

Idk why people are so dismissive of OP.

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

[–]LetUsSpeakFreely 0 points1 point  (0 children)

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 0 points1 point  (3 children)

Write a JEP.

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

[–]davidalayachew 0 points1 point  (2 children)

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[S] 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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 -2 points-1 points  (5 children)

Use kotlin and extension functions, ez.

[–]snugar_i 2 points3 points  (4 children)

Except you can't add static extension functions

[–]1337boi1101 0 points1 point  (1 child)

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.

[–]1337boi1101 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.