I've updated the trunk branch to have version 6.0.0-SNAPSHOT and set the min Java version to 11. This is just easier than than jumping straight to 17. If noone objects, i will raise the min Java version to 17 in the coming days or weeks.
On 2025/11/08 09:05:27 PJ Fanning wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
