Breaks SpringBoot application about radon HOT 8 CLOSED

Update: I wasn't thinking very carefully about this issue and realized why this is happening while I was having a bowl of cereal.

In a SpringBoot application, it seems all the classes are moved into the BOOT-INF/classes directory; however, the classes retain their names (meaning, classes don't have strange names of something like "BOOT-INF/classes/some/class/MyClass").

I suppose that this would require a special handling of SpringBoot applications (or similar) to specifically move the classes into their correct directory within the ZipFile.

from radon.

So, this is the tree structure of obfuscated jar

.
├── BOOT-INF
│   └── lib
│       ├── asm-6.2.jar
│       ├── ...
├── META-INF
│   ├── MANIFEST.MF
│   └── maven
│       └── hello.jatin
│           └── hello
│               ├── pom.properties
│               └── pom.xml
├── hello
│   └── jatin
│       ├── Application.class
│       ├── DataClass.class
│       ├── HelloController.class
│       └── SerializableClass.class
└── org
    └── springframework
        └── boot
            └── loader
                ├── ExecutableArchiveLauncher.class
                ├── ....

and this of original jar

.
├── BOOT-INF
│   ├── classes
│   │   └── hello
│   │       └── jatin
│   │           ├── Application.class
│   │           ├── DataClass.class
│   │           ├── HelloController.class
│   │           └── SerializableClass.class
│   └── lib
│       ├── asm-6.2.jar
│       ├── ...
├── META-INF
│   ├── MANIFEST.MF
│   └── maven
│       └── hello.jatin
│           └── hello
│               ├── pom.properties
│               └── pom.xml
└── org
    └── springframework
        └── boot
            └── loader
                ├── ExecutableArchiveLauncher.class
                ├── ...

Why is hello/jatin/ directory top level in obfuscated jar while it is nested inside BOOT-INF in original jar?

from radon.

Also, if I obfuscate spring boot jar with Radon, and then run it I get this error:

Caused by: java.lang.IllegalStateException: Unable to open nested entry 'BOOT-INF/lib/maven-surefire-common-2.22.1.jar'. It has been compressed and nested jar files must be stored without compression. Please check the mechanism used to create your executable jar file

while the backup jar runs fine.

from radon.

That can probably be fixed by changing the zip compression algorithm to a store. By default, Radon uses the default compression algorithm (most likely deflate or deflate64).

from radon.

@ItzSomebody any idea about change of directory structure issue? Is that the expected behaviour or a bug?

from radon.

Not expected behavior.

Edit: The behavior is actually expected, see below.

from radon.

Update: I wasn't thinking very carefully about this issue and realized why this is happening while I was having a bowl of cereal.

Spoken like a true developer

from radon.

Meet the same problem in my SpringBoot jar file , this BUG will fix in next version?

from radon.