You need to convert the found resource to URI. It works on all platforms and protects you from possible errors with paths. You must not worry about how full path looks like, whether it starts with ‘\’ or other symbols. If you think about such details – you do something wrong. ClassLoader classloader = Thread.currentThread().getContextClassLoader(); … Read more
There seem to be some bugs with the implementation referred to by Thilo, and also copy and pasted on other sites verbatim: ByteBufferBackedInputStream.read() returns a sign extended int representation of the byte it reads, which is wrong (value should be in range [-1..255]) ByteBufferBackedInputStream.read(byte[], int, int) does not return -1 when there are no bytes … Read more
Answer Here is a temporary solution , which can be improved to use Java 8 Streams and Lambdas. int[] count = {0}; try { Files.walkFileTree( Paths.get(dir.getPath()), new HashSet<FileVisitOption>(Arrays.asList(FileVisitOption.FOLLOW_LINKS)), Integer.MAX_VALUE, new SimpleFileVisitor<Path>() { @Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException { System.out.printf(“Visiting file %s\n”, file); ++count[0]; return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFileFailed(Path file, … Read more
Because your background thread is devoted entirely to watching, take() is the right choice. It effectively hides the platform dependent implementation, which may either forward or poll. One of the poll() methods would be appropriate if, for example, your background thread also needed to examine other queues in series with the WatchService. Addendum: Because the … Read more
The direct NIO buffers use unmanaged memory. It means that they are allocated on the native heap, not on the Java heap. As a consequence, they are freed only when the JVM runs out of memory on the Java heap, not on the native heap. In other terms, it’s unmanaged = it’s up to you … Read more
Long story short: java.io.File will most likely never be deprecated / unsupported. That said, java.nio.file.Path is part of the more modern java.nio.file lib, and does everything java.io.File can, but generally in a better way, and more. For new projects, use Path. And if you ever need a File object for legacy, just call Path#toFile() Migrating … Read more
No, this exception cannot be avoided. The exception itself occurs inside the the lazy fetch of Files.walk(), hence why you are not seeing it early and why there is no way to circumvent it, consider the following code: long size = Files.walk(Paths.get(“C://”)) .peek(System.out::println) .mapToLong(this::count) .sum(); On my system this will print on my computer: C:\ … Read more
Java 8 provides a nice way for that: Files.walk(path) This method returns Stream<Path>.
Ron Hitches in his excellent book Java NIO seems to offer what I thought could be a good answer to your question: Operating systems perform I/O operations on memory areas. These memory areas, as far as the operating system is concerned, are contiguous sequences of bytes. It’s no surprise then that only byte buffers are … Read more
My experience with larger files sizes has been that java.nio is faster than java.io. Solidly faster. Like in the >250% range. That said, I am eliminating obvious bottlenecks, which I suggest your micro-benchmark might suffer from. Potential areas for investigating: The buffer size. The algorithm you basically have is copy from disk to buffer copy … Read more