When a Java file is compiled the output is written to a class file which can then be read by the Java Virtual Machine. For it to be able to read an execute the class file the code is compiled into bytecode. Bytecode is essentially instructions that the JVM reads and performs, and is similar to what assembly languages look like[33]. In the class PreprocessedBuilder the decompiler seems to have stumbled upon some code that it has flat out failed to decompile, leaving us with a combination of Java code and JVM instructions, seen in listing 5.17, that throw a bunch of compile time and
syntax errors. This class is a part of the diff algorithm and by combining what we know about the algorithm with how the rest of the class and the scrambled code look, we can say that there is at least some sort of String manipulation going on. We do have the source code for the diff algorithm, so it is not a big problem as such, but whatever code was originally there was sufficiently complicated for the decompiler to fail.
Listing 5.17: A small code snippet from the class PreprocessedBuilder. The full version can be seen in listing A.4 in appendix A
1 metadata[kl + 1];
2 1;
3 JVM INSTR dup2 ;
4 JVM INSTR aaload ;
5 JVM INSTR new #93 <Class StringBuilder>;
6 JVM INSTR dup_x1 ;
7 JVM INSTR swap ;
8 String.valueOf();
9 StringBuilder();
10 met_p.name;
11 append();
12 " ";
5.8 Summary
At the start of this chapter we decided that we wanted to use version 1.5 as the basis of our update.
This meant that first we would need to decompile the class files using the decompiler we found in the previous chapter in order to recover the source code. As we have seen, most of the errors the decompiler has produced have had an easy solution but coupled with the amount of errors it has taken some time to correct them all. So far it looks like decompiling the class files is a viable option but we have yet to test our new classes. We have of course also had the benefit of having an older source code version available which has helped us a great deal. It is fully possible that some of them still contain run time errors or bugs that are not highlighted by our IDE, but version 1.5D has the potential to work. If we had recieved the source code for version 1.5 earlier, when we asked the previous developers, we could have saved a lot of time. As it is we now have to decide on which source code version we will proceed with.
Chapter 6
Reconstructed Code vs Original
During a project the circumstances on which the current effort is made may change. New infor-mation may be revealed that can make some of the work no longer useful or change the direction in which the project is going. Adaptability is important in software engineering and can often be decisive when it comes to how successful a project is. In our case we have found the source code, for version 1.5, that we thought had been lost and which our current course of action was based upon. We will now take a look at our plan and decide on whether or not to make any changes.
Before acting further on our plan however, to finish things off with our decompiling effort, it would be interesting to see just how successful we were and to do that we will compare the 1.5D classes to the original 1.5 classes.
6.1 Revising our Plan
With the source code finally in our hands we have a new decision to make, we can either continue with our original plan or adjust it to reflect the new conditions. What we originally intended to do was to proceed with compiling and deployment testing of the classes, which are steps 3 through 5 in section 4.2. The compiling step is a somewhat trivial step as it would only involve an alteration of the ant build script, or maybe not even that since Eclipse compiles all our classes for us we could simply copy these into our war file, replacing the old ones. The deployment step would be a bit more interesting as it would show us if we were successful in reconstructing the source code but with the amount of classes that we have it would be time consuming to find out which classes would need more work.
6.1.1 Adjustment
Since we now have the original source code and to keep things interesting we will however skip these steps and jump straight to the second part of our plan, table 5.3. Perhaps the most pressing issue here is making sure that Joly is stable and to solve this we will have to look for and correct any code that might be causing it to crash, which means that we will be doing step 5 first. We have already tried to analyze the memory and cpu usage and did not find any serious problems there, so the code it self will need to be reviewed and the application tested.