title: Massive Refactoring in Spring Java EE
body: <p>I'm doing a massive refactoring on a Spring-Java EE business application. However, all the refactoring is going to be within the many static classes that we use as utility classes (validators, algorithms, object processing logic, resource management, nifty utilities etc.), not within controllers and persistance classes.</p>
  
  <p>Also, the critical controllers which use the methods from these static utility classes will not be affected as I'm making the changes as transparent as possible.</p>
  
  <p>Things is, I'm the owner of some controllers, so I can go in and make any changes required to facilitate the changes in my static utility classes. For example, if I changed a method to throw a custom exception, then I can go into the controller as well and handle that exception gracefully.</p>
  
  <p>However, it's a large project and there are many other developers working on it, many of whom use those static utility classes day in and day out. So if I throw new Exceptions, create new overloads etc., it's going to break legacy code.</p>
  
  <p>I'm already growing tired of writing compatible (read: crippled) code that is not semantic, wraps around existing ugly logic, and does not allow me to make more flexible designs.</p>
  
  <p>Considering that we do have a decent (precise: 2 months) distance from the production day, is it ok for me to ask all developers to refactor their code as per my new contracts, or do I keep on writing legacy-garbage wrapped code that doesn't really help anything?</p>