Question regarding Manifest in Java jar file

Question

Hi All,

Is is mandatory to have classpath inside a Manifest file inside the java jar file? can we do work without having the classpath inside it?

The reason why I am asking this is because I have a jar file for a server application. When I tried to connect many connections with Server, Server went down and the error was "Too many open files", when searched about it, I found one Sun Bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446657 . Then I checked and i was having a classpath entry in the Jar file. So this question arises.

Edit: My code for Filr read is :

// Creating a new File instance
   File file= new File(fileName);  

   // Creates a DataInputStream that uses the specified underlying InputStream.
   DataInputStream input = new DataInputStream(new FileInputStream(file));
   Data = new byte[(int)file.length()];

   // Reads  bytes from the  input stream and stores them into the buffer array Data.
   input.read(Data);

   // Closes this input stream and releases any system resources associated with the stream. 
   input.close();

Is anything wrong with it leading to too many pen files? Thanks, Tara Singh

Answer 1

The Class-Path entry in a Jar manifest file is entirely optional, many working Jar files do not use that field.

Answer 2

An executable JAR must reference all the other dependent JARs it requires through the Class-Path header of the manifest file. The environment variable CLASSPATH and any class path specified on the command line is ignored by the JVM if the -jar option is used. Apart from that, your link to bug database indicate that it is a closed bug.

Answer 3

The entry is completely optional, but the bug you are pointing to is related to compilation, not runtime, so it is highly unlikely that this is the problem.

Application Servers are often very file hungry, and if nothing has been done to increase the limit of open files, the default may not be high enough.

On CentOS for example, we found that even in QA (not load testing, just functional testing) a server could max out its ulimit with JBoss 4.2.

EDIT: The only thing wrong with the code that you posted in terms of holding files open is that you should use finally to close your stream. In a server application, it could be that this code often throws an exception, causing files to not be closed (because you don't close them in a finally) and over time those open file handles add up. There are other issues in how you are doing it (like relying on the available() to determine the size of the byte array), but that should not affect your problem.

Another possibility is that under *nix systems sockets consume the same resource as files, so it could be that you have too many sockets (above what the system is configured to allow) open, causing this code to be unable to execute.

Answer 4

Be sure that you close a file after reading it.

If you're reading the contents of a file into a byte array in a loop, are you closing the file before you read the next one?