On Fri, Dec 17, 2021 at 6:24 PM Vladimir Sitnikov <
[email protected]> wrote:
> >Note removing the classes would break API compatibility
>
> I do not think keeping the class with "every method throws" is much better
> than just removing the class.
>
Agreed! I also don't want to do "every method throws". That indeed wouldn't
help. I want
* doesn't ever listen on any ports
* doesn't ever do unsafe deserialization (or otherwise unsafely consumes
data)
* otherwise behaves as can be expected given its existing configuration
* use of a problem library class means an error message on startup, but
still startup and perhaps working (other) logging
* use of a problem main() entrypoint logs an error and exits
* drop in binary replacement jar with full binary compatibility: if it
starts up now it will still start up
The reason to keep the classes and their public+protected API is to support
people who have used the library as a library.
Imagine some software that has something like:
public class CustomJMSAppender extends JMSAppender {
// XXX try and hardcode JMS, am not allowed JMX console access, YOLO
private final static String MY_PROVIDER_URL = "jms:something:something";
public CustomJMSAppender() {
this.setProviderURL(MY_PROVIDER_URL);
}
public void setProviderURL(String providerURL) {
super.setProviderURL(MY_PROVIDER_URL);
}
}
log4j being a flexible library full of extension points with public
non-final classes and many many users makes it almost a certainty someone
is stuck maintaining a system like this.
Without the source code.
On Java 1.4.
If we delete JMSAppender, and then that poor admin replaces
log4j-1.2.17.jar with log4j-1.2.18.jar, good chance their software won't
start.
Does that make sense?
Cheers,
Leo
