Why hasn't Java deprecated java.io.File in favour ...

# random

[Adam S]

Why hasn't Java deprecated java.io.File in favour of java.nio.Path? Is there a plan to do that?

[Jaap Beetstra]

I doubt there is a plan. Despite all its issues, java.util.Date is not deprecated either (interestingly, the javadoc does not even mention the java.time package).

[Jaap Beetstra]

I don't use the nio-package often; why do you consider java.nio.Path superior to java.util.File?

[Stefan Oltmann]

I guess because it’s „new“ 😄

[Chrimaeon]

“New” - it was introduced in Java 1.7 😅 like more than 10 years ago. the “n” in .nio. stands for Non-Blocking ;-)
So both of the “file” API have their use case.

[Stefan Oltmann]

https://jenkov.com/tutorials/java-nio/index.html

Sometimes NIO is claimed to mean Non-blocking IO. However, this is not what NIO meant originally. Also, parts of the NIO APIs are actually blocking - e.g. the file APIs - so the label "Non-blocking" would be slightly misleading.

[Klitos Kyriacou]

@Jaap Beetstra
> I don't use the nio-package often; why do you consider java.nio.Path superior to java.util.File?
For just one example of how nio is better than io, try this:

val file = File("some-file")
    val deleted = file.delete()
    if (!deleted) {
        // How on Earth do you find out why it couldn't be deleted?
    }

Versus:

val path = Path("some-file")
    Files.delete(path)  // throws exception with useful explanatory message

Also, Kotlin has some useful exceptions on java.nio.file.Path

[Stefan Oltmann]

Thanks for the hint, Klitos. Better exceptions would be a good reason to switch for me.

[Adam S]

why do you consider java.nio.Path superior to java.util.File?

More than anything, it's the inconsistency that bugs me. Sometimes I'll be using multiple libraries, and some use File, and others use Path, so I have to constantly convert between them.

[Stefan Oltmann]

I hope one day we can all agree on kotlinx-io (by the time the missing features are implemented)

[Adam S]

URL is being phased out https://bugs.openjdk.org/browse/JDK-8296385, so it's conceivable that File and java.time.Date will be phased out too 🤞

[Stefan Oltmann]

For java.util.Date there are good reasons. It has some flaws that got fixed by integrating joda-time (now known as Java time)

[Stefan Oltmann]

I don’t see why File should be phased out, if it works. Just because it has booleans rather than exceptions on file deletion?

[Stefan Oltmann]

I believe nobody is using Java.util.Date in a production project due to its flaws.
More likely they will use Joda time or already Java time.
So phasing it out shouldn’t have that much of an impact.

It’s another story with the old File API

[Klitos Kyriacou]

There are many more deficiencies in java.io.File. For another example, File.createTempFile has a potential security vulnerability which is fixed in java.nio.file.Files. I can't think of anything that File can do that java.nio.file.Files can't. So even if it's just for those two issues (there are probably more), applications might as well just stick to Files for consistency. Note that other <http://java.io|java.io> classes are still useful.

[Stefan Oltmann]

ChatGPT also says that performance of NIO could be better due to its design. 🤔

I just decided to at least provide an Java NIO API:
https://github.com/Ashampoo/kim/pull/94/commits/e185f158b6f4e237d6749c742a2ed93efafc61bc

I think in the future I will dive deeper into NIO and craft a ByteReader implementation that makes use of the performance. Right now it's just creating a InputStream and reads from that - I guess that's not the best performance, right?