3 Incorporated comments into answer.
source | link

Too long to put in a comment, so adding as an answer:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem as although the Java garbage collector does close your FileOutputStream (by calling finalize), it is not a good idea to rely on it because it runs unpredictably.

. So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

Too long to put in a comment, so adding as an answer:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem as although the Java garbage collector does close your FileOutputStream (by calling finalize), it is not a good idea to rely on it because it runs unpredictably.

So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

Too long to put in a comment, so adding as an answer:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem. So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

2 Updated Answer
source | link

Too long to put in a comment, so adding as an answseranswer:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem as although the Java garbage collector does close your FileOutputStream (by calling finalize), it is not a good idea to rely on it because it runs unpredictably.

So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

Too long to put in a comment, so adding as an answser:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem as although the Java garbage collector does close your FileOutputStream (by calling finalize), it is not a good idea to rely on it because it runs unpredictably.

So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

Too long to put in a comment, so adding as an answer:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem as although the Java garbage collector does close your FileOutputStream (by calling finalize), it is not a good idea to rely on it because it runs unpredictably.

So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

1
source | link

Too long to put in a comment, so adding as an answser:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem as although the Java garbage collector does close your FileOutputStream (by calling finalize), it is not a good idea to rely on it because it runs unpredictably.

So this is not a result of Unix or Linux doing anything wrong but inherent to your application.