Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Files not writing, closing files, finalize()

Reply
Thread Tools

Files not writing, closing files, finalize()

 
 
J. Davidson
Guest
Posts: n/a
 
      11-17-2008
J. Davidson wrote:
> Joshua Cranmer wrote:
>> Note that this feature is actually relatively common in high-level
>> languages, buffering output data. Remember that something like disk
>> access is actually very expensive, so buffering is a tremendous boost
>> in speed.

>
> Anyone want to know why there's two layers of buffering in Java?


Darn, no bold here? Oh well ...

- jenny
 
Reply With Quote
 
 
 
 
Lars Enderin
Guest
Posts: n/a
 
      11-17-2008
J. Davidson skrev:
> J. Davidson wrote:
>> Joshua Cranmer wrote:
>>> Note that this feature is actually relatively common in high-level
>>> languages, buffering output data. Remember that something like disk
>>> access is actually very expensive, so buffering is a tremendous boost
>>> in speed.

>>
>> Anyone want to know why there's two layers of buffering in Java?

>
> Darn, no bold here? Oh well ...
>

*Bold* works for me.

 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      11-17-2008
J. Davidson wrote:
> Anyone want to know why there's two layers of buffering in Java?


This is not phpBB. This is Usenet, which is generally pure text. The
standard way of indicating boldness in pure text is with *a pair of
asterisks.*

> It's not that Java doesn't trust the OS buffering. It's because each
> trip through JNI to call an OS API routine is expensive.


I'm not an expert as to where the buffering is, but I'm pretty sure the
call to the OS-level write routines are expensive in and of themselves.

> Another fifty years from now we'll probably have a big teetering tower
> of abstractions and I/O will get buffered at six or seven layers instead
> of just two.


So? There's already high-level API buffering, filesystem buffering, and
probably disk-level buffering as well. As long as they can be reasonably
guarded against concurrency issues, there's no problem.
>
> Wait, make that three. I think most modern disk controllers do some
> buffering of their own, because waiting for the right spot on a platter
> to rotate under the write head is expensive, and waiting for the head to
> move to a different cylinder is even more expensive.
>
> - jenny



--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-17-2008
J. Davidson wrote:
>> Darn, no bold here? Oh well ...


Lars Enderin wrote:
> *Bold* works for me.


By design, Usenet is supposed to be usable in raw text mode. It is
bad form to embed HTML, so we use conventions like slash for /italics/
and asterisk for *bold*. Some newsreaders interpret those
conventions, and even grey out sigs set off by "dash dash space" ("--
") on a line by itself. That is up to the newsreader. The rest of us
do it by imagination.

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-17-2008
J. Davidson wrote:
>> Another fifty years from now we'll probably have a big teetering tower
>> of abstractions and I/O will get buffered at six or seven layers instead
>> of just two.


Joshua Cranmer <(E-Mail Removed)> wrote:
> So? There's already high-level API buffering, filesystem buffering, and
> probably disk-level buffering as well. As long as they can be reasonably
> guarded against concurrency issues, there's no problem.


"Disks are a hack."
- Alan Cooper, /About Face/

Disks are a hack because it's too expensive to buy a terabyte of
static RAM.

Fifty years from now hard disks will be obsolete.

--
Lew
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      11-17-2008
Lew wrote:
> Fifty years from now hard disks will be obsolete.


Predictions of obsolescence tend to be woefully underestimated. After
all, the magnetic tape has not died its death yet.

I predict that fifty years from now, some people will be using hard
disks, by necessity. It may evolve into a niche role (like magnetic
tape), but it will still have one nonetheless.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-17-2008
On Sun, 16 Nov 2008 15:12:06 -0800 (PST), Matt <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>Can somebody explain to me why file output doesn't work unless the
>file is closed explicitly?
>
>{
> PrintWriter pw = new PrintWriter(new File("test.txt"));
> pw.print("Hello world!");
> pw.close(); // necessary?
>}
>


Looks ok. Try being more explicit where the file is written by
specifying drive and dir. Dump out the CWD, it may not be where you
expect. That it where test.txt will show up.

Also try a println not print. Your editor you using to look at the
file might not be happy with the missing terminator.

Even if the file were to close eventually automatically, you want to
release the considerable resources for it as soon as possible.

See http://mindprod.com/jgloss/finalize.html There in no guarantee
finalizers will ever be run.

--
Roedy Green Canadian Mind Products
http://mindprod.com
Your old road is
Rapidly agin'.
Please get out of the new one
If you can't lend your hand
For the times they are a-changin'.
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      11-17-2008
On Mon, 17 Nov 2008 07:32:59 -0800, Lew wrote:

> J. Davidson wrote:
>>> Another fifty years from now we'll probably have a big teetering tower
>>> of abstractions and I/O will get buffered at six or seven layers
>>> instead of just two.

>
> Joshua Cranmer <(E-Mail Removed)> wrote:
>> So? There's already high-level API buffering, filesystem buffering, and
>> probably disk-level buffering as well. As long as they can be
>> reasonably guarded against concurrency issues, there's no problem.

>
> "Disks are a hack."
> - Alan Cooper, /About Face/
>
> Disks are a hack because it's too expensive to buy a terabyte of static
> RAM.
>
> Fifty years from now hard disks will be obsolete.


....only if somebody designs reliable non-volatile RAM with either a multi-
decade storage and read-only lifetime or at least a million-fold increase
in the number of write cycles it can handle without failing.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      11-17-2008
On Mon, 17 Nov 2008, Martin Gregorie wrote:

> On Mon, 17 Nov 2008 07:32:59 -0800, Lew wrote:
>
>> J. Davidson wrote:
>>>> Another fifty years from now we'll probably have a big teetering tower
>>>> of abstractions and I/O will get buffered at six or seven layers
>>>> instead of just two.

>>
>> Joshua Cranmer <(E-Mail Removed)> wrote:
>>> So? There's already high-level API buffering, filesystem buffering, and
>>> probably disk-level buffering as well. As long as they can be
>>> reasonably guarded against concurrency issues, there's no problem.

>>
>> "Disks are a hack."
>> - Alan Cooper, /About Face/
>>
>> Disks are a hack because it's too expensive to buy a terabyte of static
>> RAM.
>>
>> Fifty years from now hard disks will be obsolete.

>
> ...only if somebody designs reliable non-volatile RAM with either a multi-
> decade storage and read-only lifetime or at least a million-fold increase
> in the number of write cycles it can handle without failing.


Wrong. Because tape's going to make a comeback - I GUARANTEE IT!

tom

--
Work alone does not suffice: the efforts must be intelligent. -- Charles
B. Rogers
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-17-2008
Lew wrote:
>> Fifty years from now hard disks will be obsolete.


Martin Gregorie wrote:
> ...only if somebody designs reliable non-volatile RAM with either a multi-
> decade storage and read-only lifetime or at least a million-fold increase
> in the number of write cycles it can handle without failing.


Or they develop a different form of offline storage with better
performance than hard drives and higher capacity, which I deem
extremely likely. RAM and hard drives are not the only two ways to
store data even today, so I figure other technologies are just around
the corner, and that doesn't even account for ideas not yet
conceived. Fifty years is eons of innovation in I.T. and electronics.

I have yet to have a hard drive last one decade, much less multiple
decades, so that part of the argument leaves me cold. I know of no
serious project that doesn't back up its hard drives, so I figure my
experience isn't unique.

So I take exception to the "only if" part of your argument.
Additionally, someone very well might come up with "reliable non-
volatile RAM with either a multi-decade storage and read-only lifetime
[which would then be better than hard drives are now][,] or at least a
million-fold increase in the number of write cycles it can handle
without failing."

So far no electronic medium exceeds the read-only lifetime of ink on
paper.

--
Lew
No other virtual reality system has been invented that outperforms the
novel, given a trained user.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PyGame, window is not closing, tut not helping globalrev Python 3 05-13-2008 01:26 AM
Closing popup window when closing parent window? =?Utf-8?B?Vk1J?= ASP .Net 3 02-15-2007 08:29 AM
Closing the doors 15 minutes before closing. doofus Computer Support 12 06-11-2005 08:20 AM
Closing Files E Tepp Java 1 02-02-2004 08:35 PM
Closing child window WITHOUT closing parent thomas Javascript 0 10-23-2003 04:10 PM



Advertisments