{"id":89,"date":"2016-12-27T09:39:33","date_gmt":"2016-12-27T14:39:33","guid":{"rendered":"http:\/\/computermoose.topshot.com\/?p=89"},"modified":"2016-12-27T09:39:33","modified_gmt":"2016-12-27T14:39:33","slug":"the-value-of-decompiling-java-code","status":"publish","type":"post","link":"http:\/\/computermoose.topshot.com\/index.php\/2016\/12\/27\/the-value-of-decompiling-java-code\/","title":{"rendered":"The Value of Decompiling Java Code"},"content":{"rendered":"

The inspection of a stack trace is a crucial part of a developer\u2019s methodology for determining the source of an error or bug. In some environments, the stack trace can be quite large. I was once working in a WebSphere environment and was asked to try and determine why some of the application related stack traces we were seeing did not include any application code references. Without a reference to the application code, we had no idea where the exception originated.<\/span><\/p>\n

In a WebSphere environment, users are supposed to throw a ServiceBusinessException (this is an IBM created exception class). This tells the WebSphere framework that a backend application error occurred. With our application however, we frequently saw that this exception didn\u2019t show where the error originated. By reviewing lots of log files, I noted that sometimes the stack trace did point to the source code line where the exception was thrown and sometimes it didn\u2019t. It was most puzzling and I couldn\u2019t figure out what was going on. At the same time, I did notice that whenever a Java IllegalArgumentException was thrown, a complete stack trace was presented.<\/span><\/p>\n

Using SoapUI, I fed the application some bad data on purpose. I knew exactly which ServiceBusinessException was being thrown within the application. The line of code looked something like this:<\/span><\/p>\n

throw new ServiceBusinessException(\u201cSome error message.\u201d); <\/span><\/pre>\n
I had a wild idea. Let\u2019s replace that line and throw an IllegalArgumentException and see if we would get a full stack trace or a stack trace that was missing the crucial lines. If we got a good stack trace, this would infer something amiss within ServiceBusinessException. If we still got a bad stack trace, this would imply something in our code was messing up the stack or the exception handler. So the new line of code looked like this:<\/span><\/p>\n
throw new IllegalArgumentException(\u201cSome error message.\u201d); <\/span><\/pre>\n
I ran the test. The stack trace that appeared in the log file was complete! So I now had some evidence that showed the culprit to be the ServiceBusinessException itself and not something in the application. So within WID (the WebSphere modified version of Eclipse) I placed the cursor on the word \u2018IllegalArgumentException\u2019 and pressed the F3 key (\u201cOpen Declaration\u201d). Since I had installed the JAD (Java Decompiler) plugin, WID was able to decompile the IllegalArgumentException.class into real Java source code. What I saw was the following code:<\/span><\/p>\n
public <\/b>IllegalArgumentException(String s) {\r\n    super<\/b>(s);\r\n}<\/span><\/pre>\n
Then I did the same thing for ServiceBusinessException:<\/span><\/p>\n
public<\/b> ServiceBusinessException(Object data)\r\n{\r\n    if <\/b>(data instanceof<\/b> DataObject)\r\n        this<\/b>.data = new<\/b> XMLExternalizableDataObjectHolder((DataObject)data);\r\n  else<\/b>\r\n    this<\/b>.data = data;\r\n}<\/span><\/pre>\n
The first thing I noticed by perusing the decompiled source code was that the ServiceBusinessException constructor did not call the super() method. That did not look right to me. Was that a bug since after all, they both extended class RuntimeException? With further inspection, I noticed that ServiceBusinessException had a second constructor which did include the call to super(). It looked like this:<\/span><\/p>\n
\r\npublic<\/b> ServiceBusinessException(Throwable cause)\r\n{\r\n    super<\/b>(toString<\/i>(cause), cause<\/i>(cause));\r\n    if <\/b>(cause != null<\/b> && cause.getClass() ==  \r\n        com\/ibm\/websphere\/sca\/ServiceBusinessException)\r\n    {\r\n        \/\/ a bunch of logic goes here\r\n    }\r\n}<\/span><\/pre>\n
So I modified my code to force invocation of this second constructor of ServiceBusinessException and test the theory that the missing call to super() was the source of the bug. My code ended up looking like this:<\/span><\/p>\n
IllegalArgumentException exc = new IllegalArgumentException(\u201cSome error message.\u201d); \r\nthrow new ServiceBusinessException(exc);<\/span><\/pre>\n
Suddenly my stack trace looked correct. This then was the confirmation I needed to demonstrate that ServiceBusinessException had a bug in it (a missing call to super()). I don\u2019t know how long it would have taken me to find this bug had I not had the ability to decompile the two exception classes and compare them. I am convinced, however, that it would have taken much longer than it did take.<\/span><\/p>\n
Adding JAD and the JAD plugin to Eclipse or WID is very easy. The JAD plugin can be found at http:\/\/sourceforge.net\/projects\/jadclipse\/<\/a> . JAD can be found at http:\/\/www.varaneckas.com\/jad\/<\/a>.<\/span><\/p>\n
Place the JAD decompiler (jad.exe) in a directory of your choice. In a Unix environment, you may need to make JAD executable. Place the JAD plugin (the jar file) in Eclipse plugins directory. Restart Eclipse and go to Window \u2192 Preferences \u2192 Java \u2192 JadClipse. Change the \u2018Path to decompiler\u2019 location to fully reference the jad.exe file wherever you have placed it.<\/span><\/p>\n
The \u2018class\u2019 file association must be updated (in case it wasn\u2019t automatically done through the plugin installation). Go to Window \u2192 Preferences \u2192 General \u2192 Editors \u2192 File Associations. For file type \u201c.class\u201d, add \u201cJadClipse Class file Viewer\u201d as the default editor.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
The inspection of a stack trace is a crucial part of a developer\u2019s methodology for determining the source of an error or bug. In some environments, the stack trace can be quite large. I was once working in a WebSphere environment and was asked to try and determine why some of the application related stack … Continue reading “The Value of Decompiling Java Code”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[1],"tags":[],"class_list":["post-89","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p7qelO-1r","jetpack-related-posts":[],"_links":{"self":[{"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/posts\/89","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/comments?post=89"}],"version-history":[{"count":6,"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/posts\/89\/revisions"}],"predecessor-version":[{"id":95,"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/posts\/89\/revisions\/95"}],"wp:attachment":[{"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/media?parent=89"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/categories?post=89"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/computermoose.topshot.com\/index.php\/wp-json\/wp\/v2\/tags?post=89"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}