AssertionError during decompilation about krakatau

[Storyyeller]

Can you post the complete jar please?

[greenozon]

sure
https://www.sendspace.com/file/gx967g
delit after get
https://www.sendspace.com/delete/gx967g/96b2e558af10d4bffc7ccf988a00e5a8

2. the other question is: why does the Krakatau not see the generic class like this:

//ClassLoaderError: 
//ClassNotFoundException: javax/crypto/NoSuchPaddingException 

[Storyyeller]

Ok, I'll look into it.

As for the javax/crypto/NoSuchPaddingException thing, that's because it needed to explicitly know about every jar that contains referenced classes.In the case of NoSuchPaddingException, it is in jce.jar, rather than the core rt.jar, so you need to pass the path to jce.jar using the -path option.

[Storyyeller]

This particular bug should be fixed now, but there's a much trickier bug I found in a different class in the same jar.

Anyway, I'd recommend running Krakatau with assertions disabled (pass -O to python). Assertions sometimes reveal issues that could lead to incorrect results (like the second case I found), but they're mostly useful for debugging and often harmless (like in this case). Plus, running with assertions disabled makes decompilation slightly faster.

[greenozon]

Thanks a lot for your time & findings!
Good point regarding jce.jar, but how about this idea: if the class is a native JRE class, so the tool will be nice enough to scan the JRE/lib for *.jar and to know about native classes?
anyway, that's up to you

I'll try with -O key and also with adding jce.jar

[Storyyeller]

I've thought about that, but the method of finding jre classes differs from platform to platform and it's obviously hard to test on just one computer.

[Storyyeller]

I fixed two more bugs and the jar now decompiles without any errors.

Thanks for reporting it. The assertion failures aren't really meaningful, but I did catch one real bug in the process.