nick rothwell | project cassiel

I've been doing some messing around with MXJ projects using a couple 

of embedded file-based relational databases (HSQL DB and Apache 

Derby), and for each of them I'm seeing various file-related 

problems: failure to remove lock files, failure to open files 

properly, that kind of thing - and quite often an unexplained "Bad 

file descriptor" I/O error. Everything runs fine on my G4 TiBook; the 

errors are occurring on the MacBook Pro. So, I'm wondering if the 

file handling isn't quite right in the Intel Mac JVM.

I've been doing some messing around with MXJ projects using a couple  
of embedded file-based relational databases (HSQL DB and Apache  
Derby), and for each of them I'm seeing various file-related  
problems: failure to remove lock files, failure to open files  
properly, that kind of thing - and quite often an unexplained "Bad  
file descriptor" I/O error. Everything runs fine on my G4 TiBook; the  
errors are occurring on the MacBook Pro. So, I'm wondering if the  
file handling isn't quite right in the Intel Mac JVM.

java-file-io-dodgy-on-os-x-intel

i have no idea if this is related, but i remember in the past having problems porting a java application built on my power pc to windows. the problem was file io. don't remember exactly the errors i was getting, but they were runtime errors related to the file io streams.

the solution was to explicitly close and delete every stream i opened for file i/o. this meant i had to turn several anonymous classes into local variable declarations, and manually close them.

all stuff i didn't have to do on the powerpc.

i have no idea if this is related, but i remember in the past having problems porting a java application built on my power pc to windows.  the problem was file io.  don't remember exactly the errors i was getting, but they were runtime errors related to the file io streams. 

the solution was to explicitly close and delete every stream i opened for file i/o.  this meant i had to turn several anonymous classes into local variable declarations, and manually close them.
all stuff i didn't have to do on the powerpc.

You should explicitly close every stream you open in any case, otherwise 

you're leaving it to a finalizer in the stream class that won't be 

Bloch goes into more detail about this in 'Effective Java' (p20-21), the 

upshot being that if you have nicely encapsulated stream use that spans 

multiple methods, you should provide a explicit termination method, a la 

close(), that clients are to call in a try-finally block.

> the solution was to explicitly close and delete every stream i opened

You should explicitly close every stream you open in any case, otherwise 
you're leaving it to a finalizer in the stream class that won't be 
called at a predictable time.

Bloch goes into more detail about this in 'Effective Java' (p20-21), the 
upshot being that if you have nicely encapsulated stream use that spans 
multiple methods, you should provide a explicit termination method, a la 
close(), that clients are to call in a try-finally block.

Robert Ramirez wrote:
> the solution was to explicitly close and delete every stream i opened
> for file i/o.


On 7 Jan 2007, at 00:01, Owen Green wrote:

> You should explicitly close every stream you open in any case, 

> otherwise you're leaving it to a finalizer in the stream class that 

I've tried coding against two different file-based embedded databases 

(HSQLDB and Apache Derby); both work fine on PowerPC and fail on 

Intel. I'll check the (relatively simple) common code again; if it's 

not there, then I can't see how two different database systems can 

nick rothwell -- composition, systems, performance -- 

> You should explicitly close every stream you open in any case,  
> otherwise you're leaving it to a finalizer in the stream class that  
> won't be called at a predictable time.

I've tried coding against two different file-based embedded databases  
(HSQLDB and Apache Derby); both work fine on PowerPC and fail on  
Intel. I'll check the (relatively simple) common code again; if it's  
not there, then I can't see how two different database systems can  
fail in the same way.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


> I've tried coding against two different file-based embedded databases 

> (HSQLDB and Apache Derby); both work fine on PowerPC and fail on Intel. 

> I'll check the (relatively simple) common code again; if it's not there, 

> then I can't see how two different database systems can fail in the same 

Sorry Nick, I hadn't meant to suggest that was a solution to your 

problem, just a general observation in passing to Robert.

Are there test suites or example apps with HSQL / Derby, and do they 

> I've tried coding against two different file-based embedded databases 
> (HSQLDB and Apache Derby); both work fine on PowerPC and fail on Intel. 
> I'll check the (relatively simple) common code again; if it's not there, 
> then I can't see how two different database systems can fail in the same 
> way.

Sorry Nick, I hadn't meant to suggest that was a solution to your 
problem, just a general observation in passing to Robert.

Are there test suites or example apps with HSQL / Derby, and do they 
work on your intel machine?

On 7 Jan 2007, at 12:04, Owen Green wrote:

> Sorry Nick, I hadn't meant to suggest that was a solution to your 

> problem, just a general observation in passing to Robert.

It has prompted me to double- and triple-check that I am closing down 

the databases properly (although both of them clean up their 

temporary files when I quit Max - but only on PowerPC).

> Are there test suites or example apps with HSQL / Derby, and do 

Good question - I was meaning to check that out - but for the time 

being I've just gone with an external MySQL database instead. MySQL 

under OS X (both PowerPC and Intel) seems to work well.

> Sorry Nick, I hadn't meant to suggest that was a solution to your  
> problem, just a general observation in passing to Robert.

It has prompted me to double- and triple-check that I am closing down  
the databases properly (although both of them clean up their  
temporary files when I quit Max - but only on PowerPC).

> Are there test suites or example apps with HSQL / Derby, and do  
> they work on your intel machine?

Good question - I was meaning to check that out - but for the time  
being I've just gone with an external MySQL database instead. MySQL  
under OS X (both PowerPC and Intel) seems to work well.

Java file I/O dodgy on OS X Intel?