Questions on the NIO.2 API

Salter, Thomas A Thomas.Salter at unisys.com
Mon Jan 31 09:18:44 PST 2011


It really needs to be stressed that applications should rarely, if ever, be dependent on a particular type of storage.  There’s no telling what different FileStores will be supported  by vendors who’ve ported Java to platforms other than Windows/Linux/Solaris.  As portable as Java is, there are still a multitude of ways for people to write non-portable code.   Let’s not create another one here.

My company has ported Java to our proprietary operating systems whose file systems are nothing like anybody else’s.  It’s amazing how often we’ve run into third party software that’s made assumptions that cause their software to fail on our systems.

Tom


From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Martijn Verburg
Sent: Monday, January 31, 2011 12:00 PM
To: Alan Bateman
Cc: nio-dev
Subject: Re: Questions on the NIO.2 API

Hi Alan,

The FileStore object's type is simply a String as opposed to a constant, enum or other defined type.  This makes it very hard to rely on for decision making (as per the if statement I have above).  I assume this is a limitation of being able to consistently detect the underlying storage type?
The FileStore name and type are really meant for display/informational purposes. Say for example someone right clicks on the FileStore to look at its properties and is shows the name, type, capacity, and space available. Maybe we need to make this clearer in the javadoc. Do you have examples in mind where you might do something differently if the volume is NTFS or FAT or whatever? The only cases that we do handle is where you want to know if the file store supports certain file attributes or not, and you can query file store specific attributes.

I think it could be made clearer in the Javadocs at the level of the class description?  Something like that type and store are almost free text field meta information?  The docs on the two getters for name and type are pretty clear ("...implementation specific..").

I instinctively thought about using storage type as an additional check. For example I may have plugged in an incorrect USB stick (with an incompatible file storage) or some dastardly Hollywood villain has inserted a storage device that's almost identical to the one that our system is used to seeing.  Pity s/he didn't know about different storage types - sound the alarm!

Far fetched? Probably yes :-)

Cheers,
Martijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110131/a7e5939d/attachment-0001.html 


More information about the nio-dev mailing list