Java 7 Introduce a new I/O package to handle File Access form the Java Virtual Machine more  ”simple”. Well thats how I actually look at it after using it in one of my sideline projects.

Although upon exploring the net on potential cause on why a new File I/O Api was developed, I found this to be the most straight forward reason. For proof that the prior Java 7 File IO api has it flaws, I listed what is indicated on the above site and give my inputs to each.

• Many methods didn’t throw exceptions when they failed, so it was impossible to obtain a useful error message. For example, if a file deletion failed, the program would receive a “delete fail” but wouldn’t know if it was because the file didn’t exist, the user didn’t have permissions, or there was some other problem.
  • Well this is quiet a start, no exception handling at all for some methods. For read, create and write process are fine since developers can handle them accordingly in their code, but the delete method (as indicated above), has no excuse at all. There should at least have a decent exception message that should be thrown. Yet is this enough for a re-architecture?
• The rename method didn’t work consistently across platforms.
  • This is interesting, a Java known to be cross platform has a method that doesn’t work in all platform. If you’re developing a Web-based Java Driven Application that is expected to run on different platforms, hold your horses first. 
• There was no real support for symbolic links.
  • I would say the symbolic links (or soft link to many) is tolerable, since this can be created. Although for me, it is more of a good addition to the File IO than a lacking on the prior.
• More support for metadata was desired, such as file permissions, file owner, and other security attributes.
  • Not much support for metadata access. With the introduction of cloud storages, File metadata access are more important now. Instead of storing files on database and add meta-data information to it. It would be more efficient if all of its information can be saved in its own metadata.
• Accessing file metadata was inefficient.
• Many of the File methods didn’t scale. Requesting a large directory listing over a server could result in a hang. Large directories could also cause memory resource problems, resulting in a denial of service.
  • Imagine using this in a enterprise application, that renders an xml file and transform it (using xslt) and display it in your screen. If this is the case for the prior File I/O, then I guess you need to revisit your design and put an improvement plan for future (possibly monolithic addition of data) implementations.
• It was not possible to write reliable code that could recursively walk a file tree and respond appropriately if there were circular symbolic links.
  • We lack symbolics then we cannot guarantee the stability of recursion with it.

I guess, the new Java 7 IO solved most of this issue. Yet still, I haven’t tried putting all of their answers to the issue above to the test. Although I did experience a bit of it in my sideline project.

My example above is just a basic file manipulation example. You can see that its more simpler to apply file management capabilities to your code using the new API.

Interface Summary:

My cents: I think it is worth checking out, although for implementations out there that uses the old File IO, its unfortunate to inform you that this is re-architecture of the File I/O, you would have to re-code your application to use it. Although it uses the same File IO objects (File, Paths etc.) so I guess, it wouldn’t be too hard to switch.