Monday, October 27, 2008

Java 7 gets "New" New I/O package

I've always hated Java I/O with all its convoluted, Rube-Goldbergish special classes with special knowledge of special systems, and the legacy readLine( ) type of garbage that brings back so many bad memories of the Carter years.

With JSR 203 (to be implemented in Java SE 7), we get a new set of future legacy methods. This is Sun's third major attempt in 13 years to get I/O right. And from what I've seen, it doesn't look good. (Examples here.) My main question at this point is where they got that much lipstick.

The main innovation is the new Path object, which seems to be a very slightly more abstract version of File. (This is progress?) You would think any new I/O library these days would make heavy use of URIs, URLs, and Schemes (file:, http:, etc.) and lessons learned in the realization of concepts like REST, AJAX, and dependency injection. No such luck. Instead we have exotic new calls like FileSystem.getRootDirectories()and DirectoryEntry.newSeekableByteChannel(). It's like we've learned nothing at all in the last 20 years.

When I want to do I/O, I want to be able to do something like

dataSrc = new DataGetter( );
dataSrc.setPref( DataGetter.EIGHTBITBYTES );
dataSrc.setPref( DataGetter.SLURPALL );
data = dataSrc.getData( uri );

and be done with it. (And by the way, let me pass a string for the URI, if I want to. Don't make me create a special object.)

I don't want to have to know about newlines, buffering, or file-system obscurata, unless those things are terribly important to me, in which case I want to be able to inject dependencies at will. But don't make me instantiate totally different object types for buffered vs. non-buffered streams, and all the rest. Don't give me a million flavors of special objects. Just let me pass hints into the DataGetter, and let the DataGetter magically grok what I'm trying to do (by making educated guesses, if need be). If I want a special kind of buffering, filtering, encoding, error-handling, etc., let me craft the right cruftball of flags and constants, and I'll pass them to the DataGetter. Otherwise, there should be reasonable defaults for every situation.

I would like a file I/O library that is abstract enough to let me read one bit at a time, if I want; or 6 bits at a time; or 1024 bits, etc. To me, bits are bits. I should be able to hand parse them if I want, in the exact quantities that I want. If I'm doing some special type of data compression and I need to write 13 bits to output, then 3 bits, then 12, then 10, and so on, I should be able to do that with ease and elegance. I shouldn't have to stand on my head or instantiate exotic objects for reading, buffering, filtering, or anything else.

I could write a long series of articles on what's wrong with Java I/O. But I don't look forward to revising that article every few years as each "new" I/O package comes out. Like GUI libraries and 2D graphics, this is something Sun's probably never going to get right. It's an area that begs for intervention by fresh talent, young programmers who are self-taught (not infected by orthodoxies acquired in college courses) and have no understanding at all of legacy file systems, kids whose idea of I/O is HTTP GET. Until people with "beginner's mind" get involved, there's no hope of making Java I/O right.



5 comments:

  1. I am a Java beginner (but in software development since more than twenty years) - but from what I have seen so far in the standard libraries of Java 6: Full ACK to your post! And I would even go further:

    In many cases file content can be a small text template only for example (for composing an email for instance) and something like public static String readContent(String fileName) would be nice.

    In Java 6 I couldn't either find a copyFile method (maybe only overlooked so far?) but at least 5 ways how it could be done (maybe that's the reason why there is no implementation available "by default"). So what about some default methods like copySmallFile (read the whole content at once and write it to destination) and copyLargeFile (uses limited buffers)?

    Why do I have to always write such basic routines again and again in every new language I am learning?

    Instead of the basic stuff that helps getting started we get frameworks and other abstract stuff...

    ReplyDelete
  2. I/O means different things to different people as there are many layers in the stack. The abstraction in the Java Platform that represents a connection to a resource identified by a URL is URLConnection. For example, url.openStream opens a connection to the resource so that you can read its contents. The abstraction is okay for many cases and may provide a starting point for your declarative API. You are right that the platform does lack utility methods to save the developer from having to deal with streams of bytes, buffering, line separators, etc. We need to address this so that the common cases are easy to use and save the developer from having to remember many of these details. In any case, high level/abstract APIs are fine for many cases but they can be awkward when you wan to do something very specific. (JNDI is good example where it can be awkward when you need to do something very specific with LDAP or DNS for example). New I/O brings APIs to address specific problems or areas. The first installation of New I/O focused on charsets, buffers, and support for multiplexed/non-blocking I/O needed when building highly scalable server applications. The second phase of New I/O must address the needs of applications and tools that want to access the file system directly. File I/O has mostly been ignored since JDK1.0. URIs can be used to locate files (also file systems when using the provider interface).

    ReplyDelete
  3. You can still use http://commons.apache.org/io/. It provides a lot of utilities you're looking for.

    ReplyDelete
  4. Anonymous3:21 AM

    Nice information, valuable and excellent design, as share good stuff with good ideas and concepts, lots of great information and inspiration, both of which I need, thanks to offer such a helpful information here. trackingtourism |

    chateautalaud |

    campbelllacebeta |

    icarustransits |

    utility-masters |

    townmillbakery |

    jamesgilbertdesign |

    bargainbrenda |

    giddenplacepropertycreative |

    compendium-media |

    ReplyDelete

Please add your comment here!