• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Portability implications for NIO

 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Consider this comment in the JSR51 spec:


An API for fast buffered binary I/O, including the ability to map files into memory when that is supported by the underlying platform.


Would memory mapped files be the thorn that breaks the portability of Java since platforms that do not support it will not run my NIO code ?
Pho
 
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many other things that NIO does other than memory mapped IO. For example, Channels, Selectors, File Locks.
And actually, the model used to implement memory mapped files is such that the code will still run on a system which does not support memory mapping.
Someone correct me if I am rong. But to do memory mapping, you start with an ordinary File. You use the new API to get something called a FileChannel out of the open file. Then you use the FileChannel object to create a MappedByteBuffer, which wraps a memory buffer of a particular region of the file.
If the underlying OS supports memory mapping, the MappedByteBuffer changes whenever the content of the file changes. If the underlying OS does not support memory mapping, the contents of the MappedByteBuffer do not change unless your Java application changes it.
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was wondering about that myself when I saw Pho's question... if the platform does not support memory mapping do you basically get a non-mapped file (instead of an IOException)? I looked at the API docs but it didnt really say.
 
Author
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not entirely sure either what happens on a platform where native file mapping is not supported. I would assume that the map() call on FileChannel would throw an IOException since it would not be able to create a mapping.
The purpose of mapping files is to be able to see, or cause, changes to the underlying file directly. Attempting to simulate it would be problematic at best.
NIO was created to leverage powerful I/O services available in the OS. To some extent, that makes it dependent on the deployment platform. If you need memory mapped files, you're unlikely to deploy it on an OS that doesn't support them.
NIO standardizes access to these things, but it necessarily ventures into that gray zone where virtual machine meets real machine.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Ron]: I'm not entirely sure either what happens on a platform where native file mapping is not supported. I would assume that the map() call on FileChannel would throw an IOException since it would not be able to create a mapping.
I'm not sure either - the book I just read didn't really address this point. However I note that the API doesn't say anything at all about the possibility of map() being completely unsupported. They could easily have declared that map() may throw UnsupportedOperationException, for example - but they didn't. Or they could've provided a canMap() method returning a boolean - but again, they didn't. It sounds to me like on any platform with a Java 1.4 JVM implementation, you can expect to be able to invoke map() on a valid FileChannel and have it return a working MappedByteBuffer.
However, the API is very picky about what behavior is and is not guaranteed for mapped files. Only a few things are explicitly guaranteed. One is that if/when you call the force() method on a MappedByteBuffer, any changes you've made to the buffer will be written to the file. (They may or may not have been written already.) Also even if you don't explicitly call force(), it's claimed that changes will "eventually" be written to the file. I don't know that I'd trust this though. Most other details of "mapped" file behavior are explicitly not guaranteed. E.g. if some other process starts working with the same file, there's no guarantee whenther changes by one process will be visible to another process. I suspect it's much like multithreaded access to any shared resource without proper synchronization different threads/processes may see different local copies of data, and the thread that completes its job last may well completely undo whatever changes were made by the previous thread. Ugh. I suppose if you're going to map() a file you should really acquire a FileLock on it first - but there again, there are few guarantees that such locks will be respected by other processes. It's really up to the operating system.
I think that the answer to Pho Tek's question is that yes, certain features of java.nio can be a real problem if you're trying to make a reliable cross-platform solution, and you unknowingly rely too much on features which are not guaranteed to work everywhere. Though to be fair - if your MappedByteBuffer doesn't catch the changes some user just made to a critical file using a text editor, it's not usually your problem if the program breaks. Silly users should know better.
Practically speaking, many of the biggest uses of NIO are in servers, where this is less of a problem. You don't have to worry as much about making sure your program works on all possible server platforms - just this one. Ummm, usually. And if someone is running other processes that interfere with your mapped file, you can expect the sysadmin to take responsibility for having the appropriate person killed.
For a product that you really need to be as cross-platform as possible while also benefiting from NIO's strengths where possible, you may need to write two versions of some critical parts or the system, and provide the user with some way specify whether or not to use things like file mapping. My guess is that this won't really be an issue very often, but it's probably worth keeping the idea in the back of your mind when analyzing a system - NIO may limit portability.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic