ppkarwasz commented on issue #2769: URL: https://github.com/apache/logging-log4j2/issues/2769#issuecomment-2461500874
@jaykataria1111, Great job! :100: > > Note: I noticed that some of our builders have complex conventions for the name of the setter: the setter for an isUnicode field should be called setUnicode and not setIsUnicode. > > +1. I removed the type check and kept the naming check and fix the compilation issues for the purpose. I had to change the name of some fields due to this. It should be a backwards compatible change. Unfortunately, changing the name of `@PluginBuilderAttribute`-annotated fields **is** a breaking change, because those names are used in the configuration file. What you should do in this case is **deprecate** the old setter and create a new one. In PR #3174 I fixed the setter problems I found. > Some of the methods had a void return type I fixed that for example changed [SocketPerformancePreferences](https://github.com/apache/logging-log4j2/blob/d229eda077c313a8a2060caa42531f6b539b1a09/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketPerformancePreferences.java#L78-L88) > > The issue is that, the check-api-comp build task fails for the purpose when I do the code change, should we ignore it? All of my changes so far are backwards compatible, but the tool thinks that these are "MAJOR" changes. Nice catch! Unfortunately changing any public signature **is** technically a breaking change. Of course the ultimate classification is up to the developers. We have two choices here: 1. Add a configuration option to the processor to change the behavior for mismatched return types from `ERROR` to `WARNING`. 2. Tell BND Baseline to ignore those changes. I am quite strict on binary compatibility, even if it concerns code that probably nobody uses. @vy, @JWT007, what do you think? Is fixing those broken setters in `SocketPerformancePreferences` worth the breaking change? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
