Currently, the Launch4j executable wrapper store the jar file in the rdata section, would it be feasible to transform this jar into tar.gz to save more space?
I haven't checked the source code of the wrapper yet so have no idea how it loads the jar into JVM. Do you think it is feasible?
If it is feasible and you think valuable, I am willing to do the change since I tested that the reduction is about 42% of a jar produced by ProGuard at the size of around 636 KB -> 363 KB. While using lzma the size is reduced by 60%.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay I have just checked the source code and understood that an executable can be used as a jar file as well.
So the way to go is something like a custom class loader that would open the executable file itself to look for the real payload then load it.
Let say, a new class LzmaTarClassLoader is packed into a jar in the beginning of the rdata section, then the class loader needs to be able to read information from the executable file like the actual class to load, the arguments to pass and the ability to suck the class from the executable on-the-fly to maintain the current tempfile-less property of Launch4j.
Moreover, other kinds of class loader can be implemented as well. (eg. decryptor)
In fact, this can be separated from Launch4j since l4j has already done its good job.
If there is a tool that would transform a jar into another form of jar that functions as above, that would do the job.
Perhaps the only concern is how to reuse the information available to Launch4j, the awareness of the existence of Launch4j in the custom class loader.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is available since 1.5 so no extra classes are needed to bundle with the custom class loader. So if the minJRE specified is 1.5, pack200 can be used with minimum extra effort.
Next we need to consider whether including the lzma library justify for the saving comparing to ZIP that Java supports by born.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently, the Launch4j executable wrapper store the jar file in the rdata section, would it be feasible to transform this jar into tar.gz to save more space?
I haven't checked the source code of the wrapper yet so have no idea how it loads the jar into JVM. Do you think it is feasible?
If it is feasible and you think valuable, I am willing to do the change since I tested that the reduction is about 42% of a jar produced by ProGuard at the size of around 636 KB -> 363 KB. While using lzma the size is reduced by 60%.
Okay I have just checked the source code and understood that an executable can be used as a jar file as well.
So the way to go is something like a custom class loader that would open the executable file itself to look for the real payload then load it.
Let say, a new class LzmaTarClassLoader is packed into a jar in the beginning of the rdata section, then the class loader needs to be able to read information from the executable file like the actual class to load, the arguments to pass and the ability to suck the class from the executable on-the-fly to maintain the current tempfile-less property of Launch4j.
Moreover, other kinds of class loader can be implemented as well. (eg. decryptor)
In fact, this can be separated from Launch4j since l4j has already done its good job.
If there is a tool that would transform a jar into another form of jar that functions as above, that would do the job.
Perhaps the only concern is how to reuse the information available to Launch4j, the awareness of the existence of Launch4j in the custom class loader.
Pack200 looks promising.
It is available since 1.5 so no extra classes are needed to bundle with the custom class loader. So if the minJRE specified is 1.5, pack200 can be used with minimum extra effort.
Next we need to consider whether including the lzma library justify for the saving comparing to ZIP that Java supports by born.
Pack200 could be a solution, the output must be a standard jar in order to work with launch4j.
Grzegorz