0

I have a java class file, 3rd part, I do not have its source, but it always throw some exception in one of its methods, I want edit that method, to add a try catch block for it.

I tried to de-compile it, but the source is not good for use, it looks obfuscated and not a complete one.

How can I do that?

virsir
  • 15,159
  • 25
  • 75
  • 109

4 Answers4

1

It is probably obfuscated, but I don't believe it's not complete.

I wouldn't recommend this approach. Why can't you just catch the exception in your code? Just do it and move on.

Another way that's preferred to editing someone else's code is to write a wrapper of your own that extends that class. Catch the exception in the method that offends you.

Both are preferable to decompiling and modifying someone else's code. That's a recipe for long-term grief.

Like this:

public class BadLibrary {
    public void toast() { throw new IllegalArgumentException(); }
}

public class MyWrapper extends BadLibrary {
    public void toast() { 
       try {
          super.toast(); 
       } catch (Exception e) {
           // log, print, or ignore.
       }
    }
}
duffymo
  • 305,152
  • 44
  • 369
  • 561
  • 1
    It is an thread runnable, I can not do that. And for its decompiled code, it looks like an anonymous inner Runnable class, and some context lost in that class. – virsir Oct 04 '12 at 02:47
  • Find a better implementation, then. – duffymo Oct 04 '12 at 09:20
1

If wrappering won't work because you can't arrange that a wrapped class is instantiated instead of the original one, then you have a difficult problem:

  • As you have observed, decompiling an obfuscated class is likely to result in source code that won't compile. And the fact that this is an inner class is likely to make this even more tricky.

  • Bytecode engineering might work; e.g. finding the new that is instantiating the faulty class, and changing it to instantiate a wrapper class. But you are going to have to write your wrapper class to instantiate the inner class reflectively ... and it will be messy because of obfuscation, access restrictions and the hidden parameters that need to be passed when a non-static nested class is instantiated.

Both of the above involve significant pain. Even if you succeed, they will leave you with future problems if you need to upgrade the 3rd-party library to a new version.

I think I would address the problem another way. For example:

  • Identify the cause of the exception, and try to implement a workaround that avoids the condition that triggers the exception.

  • Contact the support team for the product you are trying to use, and get them to give you a fix or a workaround.

  • Change to a different product that provides source code and the wherewithal to patch the problem and rebuild from source.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

The best solution I can offer is to use AspectJ and use CTW (compile time weaving) Aspects. You can wrap the method with a try/catch in an aspect. In doing this, you won't need to change any of your code and your aspect would just be injected at compile time.

Of course, using AOP adds complexity to your application so you have to be comfortable using aspects. Otherwise, I would highly recommend @duffymo's solution and wrap the 3rd party lib with your own class that contains the try/catch.

Eric B.
  • 23,425
  • 50
  • 169
  • 316
0

Which decompiler are you using? I've used JD GUI successfully

MikeB
  • 2,402
  • 1
  • 15
  • 24