Yes, agreed, but this only applies to public and protected classes and methods, I assume?
> Am 07.11.2025 um 12:36 schrieb PJ Fanning <[email protected]>: > > Based on semver, we should not remove any code that has not previously > been deprecated. > We have `@Removal` tags on much of our deprecated code so we observe > these - that is we shouldn't delete any deprecated methods with > removal set for POI 7. > I have no problem with deprecating code that no longer seems needed - > but I would object to removing it without deprecating it first. > > There are multiple jars that we use that don't have proper module-info > setups. It isn't just SparseBitSet. > > On Fri, 7 Nov 2025 at 03:17, axh <[email protected]> wrote: >> >> Hi, >> >> once 5.5.0 is released, I think we should decide what our targets are for >> 6.0. I have a list with things I'd like to see (and would like to implement): >> >> - raise the baseline JDK to 17 >> - remove obsolete code and utility classes not needed anymore and replace >> with standard JDK 17 fearures >> - modernize the code base >> - solve the last remaining JPMS compatibility problems, namely SparseBitSet >> not fully supporting the module system (uses an automatic module name) by >> either removing the dependency on com.zaxxer.sparsebitset or getting the >> author to add a real module-info.java to his project (honestly, I have very >> little hope for that to happen - the maintainer seems quite oblivious to the >> fact that automatic module names make life hard for people using jlkink). We >> could use another sparse BitSet implementation, fork the project, copy the >> source or change the POI code to not use a bitset at all. >> >> What are your thoughts? >> >> Axel >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
