Hmm... Thats what i was afraid of...
What i am trying to do is to make a new functionally identical JAR from a given input JAR but instead of using DEFLATE to compress the JAR it uses the Bzip2 Burrows Wheeler Block Matching compression.
It currently works well for an Executable JAR because of the fact there is an instaniation of a class and thus the system class loader has a "addURL" method which will add classes ,or a JAR in this case, to the classpath at runtime. This allows me to decompress the stored original JAR and add it to the system class loader. I then ultimately invoke the main method of the sorted original JAR.
i.e. this is how it currently works:
Making the bzip2 output jar:
1. convert the input jar to a temporary jar which is using the "STORE" compression technique.
2. compress the temp jar using bzip2 streams. (step 1 and 2 are performed in memory using streams)
3. copy the input jar's manifest and place it into the root directory of the output jar
4. copy the classes needed for decompressing the bzip stream into the output jar
5. copy the bzip2 compressed input jar into the output jar
running the bzip2 output jar:
1. read the stored manifest file and add the "class-path" resources to the system class loader if there is any external JARs needed
2. read the stored manifest file and find the main class.
3. decompress and add the bzip2 compressed input jar to the system class loader.
4. invoke the main method of the main class.
The problem exists that it does not work with "library jars" as they have static methods which are called. and i also need to have some sort of method protoypes in the output jar so that programs that use the input jar will be able to use the output jar as they need the same method signature.
Coupled with the fact that it seems that the system class loader does not have the "addURL" method when the method is invoked from static methods