ctubbsii commented on issue #3892: URL: https://github.com/apache/accumulo/issues/3892#issuecomment-1862503809
The exception message is not a lie. This was done in #1551 and a *lot* of care was taken to make sure that users were minimally impacted. We deprecated the old method, and added a new one that used a Set instead of an array. All of our code used the Set version. We made it a default method to warn exactly once about the deprecation, and then to call the user's implementation for the array version, in case they hadn't updated their implementation. We also made the array version a default method so that new implementations did not need to implement the deprecated method at all, and could choose to only implement its replacement. All the javadocs were updated to point users towards the replacement, and the warning was given to make sure users were notified, but not spammed. Since both methods had default implementations in the interface, the only way you would have gotten the error message is if you created an implementation that did not override either of the two methods. That could have happened with a typo (but that 's why it's good to use `@Override` annotations, so you can get compile time checks on that). If you overrode the old method, you would also have gotten a compile-time deprecation warning. Later, before 2.1.0 was actually released, we decided that the whole class should be deprecated. So, we then took great care to make sure that the old interface extended the new one, and we deprecated the entire class. A deprecation javadoc was added which pointed to the new interface, which has only a Set version of the choose method. We then documented the new SPI, with a link directly to the change to make the VolumeChooser SPI, in our release notes in the "major improvements" section. The VolumeChooser PR was the very first one linked. So, the only way I can think that a user would be negatively impacted by this is if they did not read the release notes, chose to write a *new* VolumeChooser implementation against the old interface (one written for a previous version would have required the choose method to be implemented), chose to ignore all the deprecation warnings during development of their custom VolumeChooser without reading any of the documentation or following any of the upstream development activity, didn't read any of the javadocs, and then either implemented their own choose method that took a Set and called the old method that took an array, or if they didn't implement either method on the interface at all. If a user actually got that far, I'm not sure we can do anything else for them. I'm closing this issue. I don't think there's anything more we can do, or should have done. -- 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]
