Silas De Munck

Hello Boris, I think you can just use an URLClassloader (to load the sevenzip jars), set it as the context classloader from the current thread and then let it load SevenZip things from another class afterwards? Just make sure your classes are not on the system classloader classpath? That should trigger the crash without spring? If you want, I can try to come up with something as well. A check in the init routines would definitely be a good start to prevent the jvm crashing afterwards. Can the 'no...

Hello Boris, Thanks for your response. This workaround is kind of ok, but would it be possible to give a more sensible error or exception? Currently, this issue crashes the JVM, and I saw in your source code that you do that to get a stacktrace from the jvm? However, here it only crashes with that text "Crash jvm to get a stack trace" and then the process exits. Would be nice to have an exception, or initialization check, or callback to handle this properly from the java side? Kind regards, Silas...

Hi Boris, I don't know how the 7zip internals look like, but I think a nice way to handle this would be to have the binding call a method on the creation callback class with a reference to the stream (either the ISequentialStream, or the stream index) when it has finished processing it? Then I can decide for myself what I want to do with it? Currently I just keep a list of created streams and close them afterwards, but this is probably not the cleanest solution. Can I be sure that the getStream(int...

Hello, I wonder if this is on purpose or not. When I return a ISequentialInStream from the getStream(index i) in my archive create callback, the close() is not called on that stream at the end of the read process. For the ByteArrayStream (see example snippet) this is not an issue, but I'm using a RandomAccessFileInStream(). After compression al the input files are still open. Is this on purpose, so do I need to keep track of the streams myself? I can simply create a wrapper that closes the stream...

Hello, It's a spring boot jar, built with gradle. I managed to work around it by specifying the sevenzip jars in the classpath java -cp process-0.0.4-SNAPSHOT.jar;sevenzipjbinding-16.02-2.01.jar;sevenzipjbinding-all-platforms-16.02-2.01.jar -Dloader.main=be.fed.minfin.bsaf.ProcessApplication org.springframework.boot.loader.PropertiesLauncher Is it possible that the classes loaded from your cpp binding code are not using the same classloader as the java side? If you need further info, or if I need...

The difference in execution environments is that from eclipse, the complete list of jar-dependencies is in the classpath, whereas when executing the bundled jar, it only has that in the classpath. How can I make it find the IInStream in that case?

Hello, I'm trying to create an encrypted 7z archive. Everything works fine with the build from me IDE (eclipse). However, when I build a jar, with sevenzipjbinding incluced, I get the following error: FATAL ERROR: Class net/sf/sevenzipjbinding/IInStream not found Crash jvm to get a stack trace I'm using a RandomAccessFileInStream for reading the files from the filesystem and put them in the archive. When I run the jar with -verbose, I see that it is sucessfully loading other classes from the same...