Home/ Questions/Q 743695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T08:53:35+00:00

Is is mandatory to have classpath inside a Manifest file inside the java jar

  • 0

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 https://bugs.java.com/bugdatabase/view_bug?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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0