Hacker News Reader

Comment by brudgers | Hacker News Reader

The "file" abstraction covers many different types of storage: spinning and solid state disks, in-memory structures, whatever your cloud actually uses, optical medial like DVD's, and even magnetic tape. Typically, these are managed by the underlying operating system's IO interface not Java itself.

Historically, operating systems use buffers for IO and closing the file includes flushing the buffers of in-flight data (in addition to things like deallocating pointers to files at the OS level). Without explicit instructions the operating system doesn't know when a file is no longer in use.

A programming language/environment could open and close files on every read and every write automatically. But it would entail overhead for operating system calls to allocate/deallocate nodes in the file table. For some types of programs this might be ok. For others it might be problematic, particularly those with moderate or strong dependence on IO.

View on HN

So in order to have complete automatic resource management you need to build a custom OS and possibly even custom hardware.

How would your new OS/hardware know when the "use" of the resource is complete ? Maybe the dev wanted to read just 10 bytes from a 1 GB file, maybe 100 bytes... maybe its a telnet connection which is never supposed to be closed and just kept in a pool ?

For a very small benefit of "automatic closing of resources" this looks like a huge trade-off.

Disagree that it is a small benefit. Resource management becomes so unwieldly that there's little difference between a 100k line application in Java and a 100k line application in C with regards to memory/resource management. Are you saying that moving beyond C is a "small benefit"?

And it's easy to determine when the use of the resource is complete: when there are no active pointers to the resource (the circular reference problem I don't think can happen with external resources like files).

Some languages (Python, Ruby, probably dozens of others) have constructs along these lines

  with f = open("data.txt")
    print f.readline()

The file is automatically closed at the end of the block. Those languages also have explicit open/close/seek calls to let the developer implement more complex cases.

Btw, the os closes any open file when the program ends.

Yes, you're correct that os's have some kind of rudimentary reference counting for files, but it's very inchoate and not designed as the primary method of handling file references.

There's nothing wrong with Java, but there's been a lot of effort over the last two decades put into designing alternative languages for the JVM. Scala, Clojure, Groovy, and JRuby are examples (though none are primarily in the direction of automatic file handling).

I don't think that's necessary. The 'friendly' language could have a write(file, data) command implemented at a lower level in an 'unfriendly' language as:

  // try, catch, error handling, etc.
  // omitted for clarity
  friendly_write(file,data) {
      open(file)
      write(file, data)
      close(file)
  }

It would be an engineering tradeoff of code brevity for possibly lower IO performance. Sometimes it might be worth it. Other's it might not. Java's design reflects the engineering opinion in favor of finer grained control. This is consistent with it's heritage in the line of Algol inspired languages.

Reply on news.ycombinator.com