File Path In For Java

1. File Path In For Java Free
2. File Path In For Java Programming
3. File Path In For Javascript
4. File Path In For Java Download
5. File Path In For Java Example
6. File Path In For Java Programming

How Do I Make Cross-Platform File Paths in Java?

— java, code, quality — 1 min read

Let's assume our Java application needs to write to a file at the followinglocations -

• ~/my/app/dir on *nix
• ~myappdir on Windows

1. Jul 18, 2019 The toFile method of java.nio.file.Path interface used to return a java.io.File object representing this path object. If this Path is associated with the default provider, then this method returns a java.io.File object constructed with the String representation of this path.
2. Java – Read a file from resources folder. In Java, we can use getResourceAsStream or getResource to read a file or multiple files from a resources folder or root of the classpath. The getResourceAsStream method returns an InputStream. The getResource method returns an URL and normally convert it to a File; Not working in JAR file.

Despite Java's 'write once, run anywhere' original sales pitch,many Java projects are developed, tested, and deployed exclusively on one platform.Often someone discovers they'd have a wider market if they sold their app to*nix and Windows users. Depending on details like how file paths have beenconstructed, going cross-platform can either be no big deal, or take days ofexpensive development time.

What is the difference between path, absolute path, and canonical path? Java File class provides three methods namely getPath, getAbsolutePath and getCanonicalPath. All three methods return String containing the path information of the file, but they differ with one another. GetPath: This method returns a path that was used to create a File.

Before writing to a directory, we'll check if that directory exists. Here aresome common ways to do just that.

1.7+ JDK Paths - OK

If you're on Java 7 or later, you've got access to the java.nio.file.Pathsandjava.nio.file.Files classes.

Pre-1.7 JDK Paths - OK

Prior to Java 7 we didn't have the nice helper classes above. Instead we have toconcatenate a string, which is made easier if you're using a library likeApache Commons Langor Google's Guava.

Hardcoded Unix Paths - OK

I was surprised to find out that Unix path characters seem to just work (thanks to StackOverflow user EJP'sexperience).This leaves me feeling a little uneasy, especially if your goal is to deploy tomultiple platforms and implementations of the JDK.

Hardcoded Windows Paths - NO

If the one platform you're developing, testing, and deploying on is Windows, thisis probably a familiar sight. Unfortunately, this is the code that will require abunch of String changes and lots of subsequent testing.

Who the hell am I?

I'm @MarcoBehler and I share everything I know about making awesome software through my guides, screencasts, talks and courses.

Follow me on Twitter to find out what I'm currently working on.

You can use this guide to learn how to work with files in Java through the Path API. From reading and writing files, to watching directories & using in-memory file systems.

Java’s File APIs

• The original java.io.File API, available since Java 1.0 (1996).

• The newer java.nio.file.Path API, available since Java 1.7 (2011).

What is the difference between the File and Path APIs?

The old file API is used in a ton of older projects, frameworks and libraries. Despite its age, it is not deprecated (and likely never will be) and you can still use it with any of the latest Java versions.

Nevertheless, java.nio.file.Path does everything java.io.File can, but generally in a better way and more. A few examples:

• File Features: The new classes support symlinks, proper file attributes and metadata support (think: PosixFileAttributes), ACLs and more.

• Better usage: E.g. when deleting a file, you get an exception with a meaningful error message (no such file, file locked, etc.), instead of a simple boolean saying false.

• Decoupling: Enabling support for in-memory file systems, which we’ll cover later.

(For a full list of differences between the two APIs, check out this article: https://www.oracle.com/technical-resources/articles/javase/nio.html)

Which file API should I use?

For the reasons mentioned above, if you are starting a new Java project, it is highly recommended to use the Paths API over the File API. (Even though file reads so much nicer than path, doesn’t it?)

Hence, we will focus solely on the Paths API in this article.

Paths API

To work with files in Java, you first need a reference to a file (big surprise!). As we just mentioned above, starting with Java 7, you would use the Paths API to reference files, so it all starts with constructing Path objects.

Let’s break this down:

Starting with Java 11, you should use the static Path.of method to construct paths (we’ll cover the Java7-10 equivalent in a second).

It does not matter if you are using forward slashes e.g. on Windows, as the Path API is smart enough to construct the right path, independently of the OS and any forward-backward slash issues.

So, both lines above will return the following result, when running the main method.

There are more choices you have when constructing paths: You don’t have to specify the complete path as one long string:

Instead, you can pass a sequence of strings to the Path.of method, or construct the parent directory and use it to get a child file (.resolve(child)).

Last but not least, you can also pass URIs into the Path.of call.

It sounds like a broken record, but the output…​.will be the same.

So, you have a variety of choices constructing your Path objects.

1. Constructing a path object or resolving a child, does not mean the file or directory actually exists. The path is merely a reference to a potential file. So, you’ll have to separately verify its existence.

2. Pre Java-11, Path.of was called Paths.get, which you’ll need to use if you’re stuck on older Java versions or building a library that needs some backward compatibility. Starting with Java 11, Paths.get internally redirects to Path.of.

Once you have a path object, you can finally do something with it. Let’s see what and how in the next section.

Common File Operations

When working with files or paths, you will likely be using the java.nio.file.Files class. It contains a ton of common & useful static methods, that operate on files and directories.

Use this section as a quick cheat sheet, the headings are self-explanatory.

How to check if a file exists

Checks if a file or directory exists. Also lets you specify additional parameters, to define how symlinks are handled, i.e. followed (default) or not.

When running this snippet, you’ll get a simple boolean flag back.

How to get the last modified date of a file

Self-explanatory. Returns the last date your file was modified as a FileTime object.

How to compare files (Java12+)

This is a relatively new addition to Java, available since Java 12. It compares the sizes and bytes of two files and returns the position of the first (byte) mismatch. Or, -1L if there was no mismatch.

Hence, if you are comparing two completely different files, you’ll get this as console output: the very first byte already didn’t match, hence the mismatch is position zero.

How to get the owner of a file

Self explanatory. Returns the owner of a file or directory as UserPrincipal (which extends from Principal). On Windows, this will be a WindowsUserPrincipal, which contains the user’s account name (shown below), as well as his sid, his unique security identifier on your Windows machine.

How to create temp files

Let’s break this down.

File Path In For Java Free

When creating temp files, you can specify a prefix (first param) and a suffix (second param). Both can be null.

The prefix will be prefixed (duh!) to the temp file name, the suffix is essentially the file extension, and if you leave it out a default extension of '.tmp' will be used.

The file will be created in the default temporary-file directory.

Instead of the default temp directory, you can also specify your own directory where you want the temp file to be created.

In addition to files, you can also create temp directories. As you don’t need the suffix parameter when creating dirs, you only have to choice of specifying a prefix parameter.

When running the code snippet from above, you’ll get the following (or similar) output:

Note: Temp files, contrary to popular belief, do not delete themselves. You have to make sure to explicitly delete them, when creating them in unit tests or when running in production.

How to create files and directories

You’ve seen how to create temp files, and it’s the very same thing with normal files and directories. You’ll just call different methods:

Some people are confused by this: The .resolve call does not create the file, it merely returns a reference to the (child) file you are about to create.

When running the code snippet from above, you’ll get the following (or similar) output: Bugdom game download mac.

How to get the Posix permissions of a file

If you are running your Java program on a Unix-like system (including Linux and MacOS), you can get a file’s Posix permissions. Think: '-rw-rw-rw-' or '-rwxrwxrwx' etc.

Running this on Linux or MacOS, you would get this kind of output:

Writing & Reading Files

How to write strings to files

We haven’t talked about the core of file-handling just yet: Writing to and reading from files.

Starting with Java 11 (more specifically 11.0.2/12.0, as there was a bug in previous versions), you should be using the Files.writeString method to write string content to a file. By default, it will write a UTF-8 file, which you can, however, override by specifying a different encoding.

How to write bytes to files

If you want to write bytes to a file (and in older Java versions < 11 you’d have to use the same API for writing strings), you need to call Files.write.

Options when writing files

When calling either of the write methods, the file will automatically be created (and truncated if it already exists). Which means, we wouldn’t have had to create explicit temporary files, like we did above.

If you don’t want that behavior (i.e. fail if the file already exists) and get a corresponding exception, you’ll need to pass in another OpenOption.

Using Writers and OutputStreams

Last but not least, if you want to work directly with writers or output streams, make sure to call the corresponding Files methods and not construct the writers or streams by hand.

How to read strings from files

On Java11+, you should be using the Files.readString method to read a string from a file. Make sure to pass in the appropriate file encoding; by default, Java will use the UTF-8 encoding to read in files.

How to read bytes from files

If you want to read bytes from a file (and in older Java versions < 11 you’d have to use the same API for reading strings), you need to call Files.readAllBytes.

In case the final result should be a string, you’d then have to construct it yourself, with the appropriate encoding.

Using Readers and InputStreams

As always, you can fall back to using readers or inputstreams directly. For that, use the corresponding Files methods.

A friendly reminder: File Encodings

I’ve mentioned it a couple of times over the previous sections:

You absolutely should use an explicit encoding, whenever creating, writing to or reading from files, though it’s of big help that the new Java 11 methods default to UTF-8, and not the platform-specific encoding.

Moving, Deleting & Listing Files

There are a couple of things you need to watch out for, when moving or deleting files. Let’s see some code:

How to move files

There is a Files.move method, but it does not move a file to a designated directory (which you might expect).

• test.jpg → c:temp does not work.

• test.jpg → c:temptest.jpg works.

So, you don’t move files to folders, but you 'move' them to their full new path, including the filename and extension.

File Move Options

When moving files, you can also specify how you want to move to happen, depending on the capabilities of the underlying file system.

• By default, if the target file already exists, a FileAlreadyExistsException will be thrown.

• If you specify the StandardCopyOption.REPLACE_EXISTING option, the target file will be overwritten.

• If you specify the StandardCopyOption.ATOMIC_MOVE option, you can move a file into a directory and be guaranteed that any process watching the directory accesses a complete file and not just a partial file.

How to delete files

Deleting files and folders is an area, where the Java Path API falls short a tiny bit. Let’s see why:

There is the Files.delete method, which allows you to delete files and directories, but directories only if they are empty.

There is unfortunately no flag to purge a non-empty directory, and you’ll simply get a DirectoryNotEmptyException.

How to delete non-empty directories

There are some 3rd-party helper libraries to work around this, but if you want to use a plain Java version to delete a non-empty directory tree, this is what you’ll want to do:

Files.walk will walk a file tree depth-first, starting with the directory you specify. The reverseOrder comparator will make sure that you delete all children, before deleting the actual directory.

Unfortunately, you’ll also need to catch the IOException, when using Files.delete inside the forEach consumer. A whole lot of code for deleting a non-empty directory, isn’t it?

How to list files in the same directory

There are various ways how you can list all files in a given directory. If you only want to list files on the same levels as the directory (not recursively deeper), you can use these two methods:

Note, that newDirectoryStream (as opposed to Files.list) does not return a java.util.stream.Stream. Instead, it returns a DirectoryStream, which is a class that got introduced in Java 1.7, before the release of the Streams API in Java 8.

It does, however, allow you to specify a glob pattern (like *.txt), which does the job for simple listings, and is maybe a bit easier to read than fumbling with real Streams and the corresponding filter methods.

Also note, that the streams returned by both methods must also be closed (e.g. with a try-with-resources statement), otherwise the JVM will keep the file handle on the directory open, which (on Windows) effectively locks it.

How to list files recursively

If you want to recursively list all files of a file tree, you’ll need to employ the method we used for deleting directories: Files.walk.

Note, that the stream returned by Files.walk must also be closed (e.g. with a try-with-resources statement), otherwise the JVM will keep the file handle on the directory open, which (on Windows) effectively locks it.

Absolute, Relative & Canonical Files

Let’s quickly talk about the concepts of absolute, relative & canonical paths. It’s best demonstrated with some code examples:

Relative Paths

Here, you’re constructing a new path, based on the current directory (.), even including a (.) at some point. Hence, the path is relative to your current directory, and path.isAbsolute will return false.

Absolute Paths

When you call toAbsolutePath on the path, it will get converted to an.well…​absolute path, in my case containing C:devjava-files. Note, the absolute path still contains the dots, for current directory and upper-directory!

Normalized Paths

File Path In For Java Programming

How to get rid of the dots? You’ll need to call normalize.

This normalized, absolute path, is also what you could have called the canonical path.

Relativizing Paths

Last but not least, you can also go the other way. Instead of making relative paths absolute, you can make absolute paths relative.

You’re essentially saying, given a certain base path, what is the relative path of my current (absolute) path. You’ll get the following output:

Watching Files & Directories

Some projects need to watch directories for newly created (think: uploaded) files and do something with them. You have two popular choices, when it comes to watching for changes in a directory, in Java.

Java’s WatchService

With Java 7, Java its WatchService. It is a somewhat low-level way of watching for changes in a specified directory.

The WatchService will get notified of native file events (Windows, Linux), with the notable exception being MacOS, where it falls back to polling directories for changes - which is pretty much what all other watch-libraries do by default (see next section).

Here’s some code, which you should not blindly copy & paste, but which will give you an idea of what a WatchService looks like.

Discussing a full WatchService implementation here does not really fit into the scope of this article, but note:

There’s a couple of things to watch out for (no pun intended) when using WatchService:

• You might assume that you get one event, whenever e.g. a file is updated, but this can easily result in two events: One for the updated content and one for updating the last-modified timestamp, happening within a short period of time.

• Complex IDEs like IntelliJ or even smaller text editors like Notepad++ don’t just save a file and its contents in one go. They copy contents to tmp files, delete them, then save the content to your actual file, etc. Again, there can be multiple updates happening to the same or even multiple files, whereas you, as the end-user, ideally would like to have just one updated event.

• Hence, you’ll need to apply some workarounds. The unaccepted answer with 40+ upvotes (Thread.sleep) has worked somewhat reliably for me, in the past).

Last, but not least, you might want to have a look at this superb article, which talks about Java’s WatchService, Containers and issues with bind mounts.

Apache Commons-IO

There’s another library that lets you watch directories for incoming changes: Commons IO. It has the easier API from a usage perspective, but differs in two aspects from WatchService:

1. It only works with java.io.Files, not java.nio.file.Paths.

2. It uses polling, i.e. it calls the listFiles() method of the File class and compares the output with the listFiles() output of the previous iteration to see what changed.

Again, a full implementation is outside the scope of this article, but you might want to have a look at this Gist for a working code example or use the JavaDoc on FileAlterationMonitor or FileAlterationObserver as a starting point.

Here’s what the code roughly looks like, which you should not blindly copy & paste:

In-Memory File Systems

Some developers assume that working with files always means you’ll actually have to write them to your disk.

During testing, this leads to creating a lot of temp files and directories and then having to make sure to delete them again.

But, with Java’s Path-API, there’s a much better way: In-Memory File Systems.

They let you write and read files, completely in-memory, without ever hitting your disk. Super-fast and a great fit for testing (as long as you don’t run out of memory, erm…​ ).

File Path In For Javascript

There are two Java in-memory file systems that are worth looking at.

Memory File System

One choice is Memory File System. Let’s see how you would create an in-memory filesystem with it.

Let’s break it down.

The only Memory File System-specific line is this one. You need to create a FileSystem that you will use later on to create and read/write your Paths.

By calling newLinux() or newWindows() or newMacOs() you can control the semantics of the created file system.

You are writing to a file called somefile.txt and reading in the file contents a couple of lines later.

This is the plain java.nio.file.Path-API, with one huge difference. You need to get your Path from the fileSystem, not via Path.of or Paths.get.

You’ll see why that is the case, after looking at JimFS.

JimFS

Another choice is JimFS. Let’s see how you would create an in-memory filesystem with it.

Let’s break it down.

The only Memory File System-specific line is this one. You need to create a FileSystem that you will use later on to create and read/write your Paths.

With the Configuration.unix/windows/macOs parameter, you can control the semantics of the created file system.

You are writing to a file called somefile.txt and reading in the file contents a couple lines later.

This is the plain java.nio.file.Path-API, with one huge difference. You need to get your Path from the fileSystem, not via Path.of or Paths.get.

How to make your application work with in-memory filesystems: anchors

When you look at the implementation of Path.of or Paths.get, you will see this:

File Path In For Java Download

So, while this method (and others) are very convenient, using them will imply you want to access your default FileSystem, the one your JVM is running on (WindowsFileSystem, UnixFileSystem etc.), not your in-memory FileSystem.

Hence, when wanting to make sure your code works against in-memory file systems, you must make sure to never call these helpers methods. Instead, you should always use the FileSystem or a Path as an anchor, like you are doing in the examples above.

Depending on your project (think: legacy), this is quite a challenge to pull off.

File Path In For Java Example

Fin

By now you should have a pretty good overview of how to work with files in Java.

• How to do all basic file operations, from reading, writing, listing, moving & deleting.

• How relative, absolute & canonical paths work.

• How to watch directories and files.

• How you can use in-memory file systems for testing.

Feedback, corrections and random input are always welcome! Simply leave a comment down below.

Acknowledgements

Many thanks to konrad, jonhanson and DasBrain on Reddit for pointing out various small issues (needed auto-closing of file listing streams, bugs with Files.writeString, usage of the var-keyword for better readability).

There's more where that came from

I'll send you an update when I publish new guides. Absolutely no spam, ever. Unsubscribe anytime.

Share:

Comments

File Path In For Java Programming

There's more where that came from

I'll send you an update whenever I publish a new guide.