Private classes and methods can be removed at any time. On Sat, 8 Nov 2025 at 03:54, axh <[email protected]> wrote: > > 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] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
