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]
