Recently we dug out a server running an obscure internal application; it ran inside a tomcat6/java6 and has not been maintained since years.
For starters I ripped the application (not a WAR but an "exploded" directory in /var/lib/tomcat6/webapps/ROOT) out of the server and set up a Docker environment (using debian-eol/squeeze as base), so the application is working without requiring that ages old machine. But still we need to fix a bug in the software, and we do not have any source code (nor the guys who originally wrote it) around any more.
jdGui can disassemble the individual component's jar files and .class files, but is there a way to turn the whole project (which is split in a bunch of -SNAPSHOT jars in WEB-INF/lib/, plus a bunch of OSS libraries) into something that can be loaded in Eclipse or IDEA and "simply" be recompiled?
jdGui can disassemble the individual component's jar files and .class files, [...] but is there a way to turn the whole project something that can be loaded in Eclipse or IDEA and "simply" be recompiled?
There is a way, whether you call it a "simple" way or a "non-simple" way depends heavily on whether you see the steps as simple but time-consuming, or time-consuming so therefore not simple.
Automatic disassemblers tend to produce code that rarely looks like developer written code. This means that you encounter a new issue, you have difficulty reading the code of the disassembler. Meanwhile a seasoned developer experienced in disassembly can write code by reading the Java OpCodes that compiles out to identical drop-in replacements. Both approaches increase the chance of success.
Then there's the part about reconstructing meaningful internal variable names. These are typically critical in making the code readable, which will be a prerequisite for cheap code maintenance. A seasoned developer can often read the structure of the code, assisted by observing the platform in a debugger, and make educated guesses as to what they'd name the variables. Often that is enough, but again, it is a slow process.
Finally, the structure of the code needs to be understood enough to make a correct change fixing your issue. If you are lucky, your issue impacts a small, encapsulated block of code. Under such a circumstance, a small suite of unit tests can be constructed to ensure that the fix doesn't break other undocumented, but otherwise required logic.
If you are unlucky, then your fix will require updating many different modules in concert. Again, this implies that all the modules being change have to be understood well enough to make a safe change (in an environment where they may be barely readable).
So, it can be done. It's just a lot of work, where a lot of the work may not directly contribute to the issue you want fixed. People skilled in this area can repack the JAR files such that you get some runtime debugging as the work progresses. I've done it before, and fully understand Mena's comments; but, I'm an odd bird, I liked the work.
That said, I'd only bother if you had deep enough pockets. It might be cheaper to just log the traffic into and out of the container and write a new replacement that does the same thing (but then, you'll be at risk of not logging that super-critical message that doesn't get sent except under conditions you didn't capture).