I think the code should not be removed, but moved to a legacy module that would be different from the core module. This is applicable for classes or packages deprecated (old printing for instance) but not for methods (where the rest of the class has not been deprecated).
Doing so, the "legacy module" implementation must use only the new core module implementation reainting backward compatibility. IE, the core module code will no mode be poluted with "legacy code" and would be 100% working without any legacy code.
On a middle term perspective, Classes with more than 50% members deprecated (Date anybody ?) should be analysed and considered for full deprecation (moved to "legacy module") and replaced with new ones only integrating the new way of doing. This would be an opportunity to rethink way of doing certain things that are not consistent with the rest of the platform or have been done in an über-complex way (JNDI or JAAS anybody ?).
So, javadoc should be by default only showing non deprecated things (core module). And a dedicated javadoc would show the legacy module.
This way would retain the compatibility but would show a clear "red line" between legacy and recomanded ways.
Any thoughts ? |