4 ms·

Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the e

by pram 5y ago

Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the entire thing!

AmericanChopper 5y ago
The issue I found when I was first looking at it was they were all a little bit different in random, and confounding ways. Also, whatever the “base version” of the application was had been undergoing development over the years when all these forks were being made. Looking back on it, that likely would have been the best approach. But at the time the complexity of designing something like that was a bit beyond me.
oceanghost 5y ago
I think the OP is saying each program was slightly different. Like it had been forked 200 times.
gridspy 5y ago
The OP wasn't re-writing them. Instead the OP fed the old version into a tool (Disassembler) which spat out terrible source code, worse than the original with no comments and bad variable names. This was the only way to get source at all. Then they made the disassembled source compile in a really nice way. Finally the boss asked them to make huge changes to this horrible source with time pressure.
- AmericanChopper 5y ago
  Pretty much this. A lot of the work would have been roughly equivalent to trying to de-minify some JS. With a modern IDE the task would have been a lot easier. I don’t know if Eclipse had refactoring assistance built into back then, but if it did, I’d never even heard of the idea. I was sitting on not much more than a year of programming experience at the time.
  - grujicd 5y ago
    Eclipse had refactoring from the start. It was pretty advanced IDE for the time.
    - pjmlp 5y ago
      It had to be, given that it was basically Visual Age for Smalltalk rewritten in Java. Hence why it had, and still keeps it, a Smalltalk like code navigation.
- Someone 5y ago
  Textually comparing disassembled code variants can be complicated because the disassembler might/will generate different names for locals. Because of that, a better approach might be to compare the byte codes of the variants first to find out in what classes the variants differ. Then treat the different class files as source code until you need to change any of them (so, variant 1 has foo1.class, bar.class, and baz.class, variant 2 has foo.class, bar2.class and baz.class, etc). Don’t immediately try to clean up their code, but ‘just’ try to figure out what they are doing (for many of them, that, hopefully, can be done from function names)

by pram 5y ago

Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the entire thing!

AmericanChopper 5y ago

The issue I found when I was first looking at it was they were all a little bit different in random, and confounding ways. Also, whatever the “base version” of the application was had been undergoing development over the years when all these forks were being made. Looking back on it, that likely would have been the best approach. But at the time the complexity of designing something like that was a bit beyond me.

oceanghost 5y ago

I think the OP is saying each program was slightly different. Like it had been forked 200 times.

gridspy 5y ago

The OP wasn't re-writing them. Instead the OP fed the old version into a tool (Disassembler) which spat out terrible source code, worse than the original with no comments and bad variable names. This was the only way to get source at all. Then they made the disassembled source compile in a really nice way. Finally the boss asked them to make huge changes to this horrible source with time pressure.

AmericanChopper 5y ago
Pretty much this. A lot of the work would have been roughly equivalent to trying to de-minify some JS. With a modern IDE the task would have been a lot easier. I don’t know if Eclipse had refactoring assistance built into back then, but if it did, I’d never even heard of the idea. I was sitting on not much more than a year of programming experience at the time.
- grujicd 5y ago
  Eclipse had refactoring from the start. It was pretty advanced IDE for the time.
  - pjmlp 5y ago
    It had to be, given that it was basically Visual Age for Smalltalk rewritten in Java. Hence why it had, and still keeps it, a Smalltalk like code navigation.
Someone 5y ago
Textually comparing disassembled code variants can be complicated because the disassembler might/will generate different names for locals. Because of that, a better approach might be to compare the byte codes of the variants first to find out in what classes the variants differ. Then treat the different class files as source code until you need to change any of them (so, variant 1 has foo1.class, bar.class, and baz.class, variant 2 has foo.class, bar2.class and baz.class, etc). Don’t immediately try to clean up their code, but ‘just’ try to figure out what they are doing (for many of them, that, hopefully, can be done from function names)