i've just joined a company that uses class-file replacement as a means to update their production systems.
I'm very uncomfortable with this as I feel that a change to java program should be done via a redeployment (WAR or EAR).
This style of deployment has also lead to the app becoming quite cumbersome because you have to try and keep your changes in as few class files as possible and minimise reuse. There are class files which are thousands of lines long.
For legacy reasons I can understand why they do this with their main system but its actually what they do on every system they build even now.
Am i right in thinking this is a bad way to manage changes (they also do this while developing)? Or am i being too pessimistic and unrealistic about how things actually get done in the real world?
I too am very wary of this practice.
I'm not 100% certain that it's a problem but it just feels wrong and I've seen 'updates' of this type fail for suspicious reasons in the past.
Apart from the dubious validity of the concept, it's also prone to human errors - such as forgetting to update all of the necessary files.
I'd be interested to hear a definitive answer from somebody with a better understanding, of classloaders and runtime linking, than mine.