Re: Best class decompiler?
Lew wrote:
I wonder what those modifications to the OP's "large JAR files such as
Hibernate" were. It's hard to imagine that the local variations that
carelessly were not maintained in a source-control system should be so
extensive or so necessary that one could not abandon them altogether, or
do as I've had to do on occasion in my career and recapitulate them from
spec.
Arne Vajh??j wrote:
It would obviously be the best to use standard all the way.
But we don't know why they made those changes. Usually stuff like
this is for bad reasons, but occasionally weird problems requires
weird solutions.
Agreed.
And regarding the loss, then shit happens. What is the chance of
Also true.
let us say losing the disk with the code and the backup tapes
being unreadable due to HW problem in the tape drive? Pretty small!
What is the change of this happening in any company worldwide in
a 10 year window? A lot bigger!
Well, you certainly are generous with all the hard work you are doing to
rationalize the OP's predecessors' carelessness.
As I mentioned, I've faced this myself a few times over the years. In fact,
even having source code might not suffice; some so-called "programmers" have a
genius for writing opaque and indecipherable code. On several occasions I've
found it more cost-effective to rewrite the changes from specifications than
to attempt to reverse engineer existing solutions.
As for justification to rewrite parts of Hibernate, I am at best skeptical.
Hibernate is a robust and rather complete set of libraries. I have to wonder
what changes it required that would not have been better served by writing
libraries or client code extrinsic to the Hibernate libraries themselves. OP?
What raises my suspicions even further is that the rewrites were performed
by people who didn't have the wisdom to protect their code against loss.
--
Lew