This is one scenario, which demonstrate the usage of java decompiler to a build engineer.
One morning, a developer walked to my cube and complained
Developer: My changes are not picked in latest build
As a build engineer, it's a familiar complaint which I usually receive.
Me: Cool !! provide me your change location in Perforce SCM tool and some time to debug.
That's the end of my short conversation. Now I started a massive search operation to find out, why the pretty girls changes are not picked :)
It's a Java based build system using Maven 2 and Jenkins.
Step 1: I made sure the code changes are picked up in last build by verifying the Change-list number available in perforce and the one Jenkins has picked during the build. Even I verified in the build machine, by checking the files it has synced. Everything is perfect, then I started wondering what's going wrong.
Step 2: Since it is a maven build, I thought to check the content of jar package, our build has uploaded to nexus repository. I downloaded and extracted it and the got the mystery .class file. Now how can I prove that her changes are picked by the build using this .class file?
Step 3: I felt the need of a java decompiler. I downloaded "cavaj" java decompiler (it's free) and installed it. Opened the mystery .class file with java decompiler and I'm glad to find her changes.
Java decompiler is used to convert Java class files into Java source code. In fact, there is an arms race brewing between decompilers and so-called obfuscators, which profess to provide Java code some measure of protection from decompilers. In essence, obfuscators remove all non-essential symbolic information from your class files and, optionally, replace it with fake symbolic information designed to confuse the decompiler
Step 4: Now for curiosity I extended further to find out why the developer complaining it is not picked. The root cause of the issue is that, developer was validating a jar file, which consumes her changes from another jar file. It's a maven dependency issue. Some how, the final jar file was not picking the right version of the dependent jar file, which is fixed later.
One morning, a developer walked to my cube and complained
Developer: My changes are not picked in latest build
As a build engineer, it's a familiar complaint which I usually receive.
Me: Cool !! provide me your change location in Perforce SCM tool and some time to debug.
That's the end of my short conversation. Now I started a massive search operation to find out, why the pretty girls changes are not picked :)
It's a Java based build system using Maven 2 and Jenkins.
Step 1: I made sure the code changes are picked up in last build by verifying the Change-list number available in perforce and the one Jenkins has picked during the build. Even I verified in the build machine, by checking the files it has synced. Everything is perfect, then I started wondering what's going wrong.
Step 2: Since it is a maven build, I thought to check the content of jar package, our build has uploaded to nexus repository. I downloaded and extracted it and the got the mystery .class file. Now how can I prove that her changes are picked by the build using this .class file?
Step 3: I felt the need of a java decompiler. I downloaded "cavaj" java decompiler (it's free) and installed it. Opened the mystery .class file with java decompiler and I'm glad to find her changes.
Java decompiler is used to convert Java class files into Java source code. In fact, there is an arms race brewing between decompilers and so-called obfuscators, which profess to provide Java code some measure of protection from decompilers. In essence, obfuscators remove all non-essential symbolic information from your class files and, optionally, replace it with fake symbolic information designed to confuse the decompiler
Step 4: Now for curiosity I extended further to find out why the developer complaining it is not picked. The root cause of the issue is that, developer was validating a jar file, which consumes her changes from another jar file. It's a maven dependency issue. Some how, the final jar file was not picking the right version of the dependent jar file, which is fixed later.
0 comments:
Post a Comment