So I see two +1 and one -1 from comitters, one user stated a +1 for updating support to Java 11+ in the next major version of Apache POI.
Unfortunately still not a very decisive outcome :( So let's ask another way: *Are you using Apache POI with Java 8 and do you think that it needs to continue to support it in the next major version? If so, please speak up so we know about it!* Thanks... Dominik. On Thu, Feb 22, 2024 at 3:59 PM Axel Howind <a...@dua3.com> wrote: > I feel really bad that I mixed up versions when I asked this. POI 5 can of > course stay on Java 8 and everybody can be using POI 5 for as long as they > want. With Java 11 having reached Premier Support EOL in September last > year, we should be really having this conversation about Java 17 for POI 6 > now. > > IMHO anyone still running on Java 8 in 2024 either does not care about > running the latest version of every library they use, or accepts that > rather sooner than later his dependencies might not provide fixes for bugs > and security issues any more. > > > * I am not aware of any dependency that we rely on that has fixes that > we can't uptake if we stick to Java 8 - ie the projects still publish Java > 8 friendly releases even if they have higher version releases that don't > support Java 8 > > We are talking about the next major release of POI that will be in > production through the coming years. Dependencies that come to mind: > - javax.xml.bind is deprecated. The natural replacement would be > jakarta.xml.bind that already requires Java 11. > - PDFBox will move to Java 11 in their next major version. > - Log4J 3 is currently in beta and has bumped the required runtime version > to Java 17 (https://logging.apache.org/log4j/3.x/release-notes.html). > > Why can’t we do the same thing as those dependencies you mentioned? > Publish a Java 8 friendly POI 5 and POI 6 using a newer Java baseline? > > > * I am not aware of any major Java runtime features that we need to > uptake that are not in Java 8 > > I am also not aware of any runtime features that POI needs that could not > have been solved in Java 4. But what we end up with is code that is slow > and adds maintenance cost that enables POI to be compatible with Java 8 and > is completely useless on Java 11+. > > - Improved I/O in Java 11: > > Take the IOUtils.copy() methods as an example. They could be replaced by > a single IOStream.transferTo() call in Java 11 but we still copy every byte > manually. > > Another example: there are several toByteARRAY() METHODS IN IoUtils that > are all implemented by calling this method: > > private static byte[] toByteArray(InputStream stream, final int > length, final int maxLength, > final boolean checkEOFException, > final boolean isLengthKnown) throws IOException { > if (length < 0 || maxLength < 0) { > throw new RecordFormatException("Can't allocate an array of > length < 0"); > } > final int derivedMaxLength = Math.max(maxLength, > BYTE_ARRAY_MAX_OVERRIDE); > if ((length != Integer.MAX_VALUE) || (derivedMaxLength != > Integer.MAX_VALUE)) { > checkLength(length, derivedMaxLength); > } > > final int derivedLen = isLengthKnown ? Math.min(length, > derivedMaxLength) : derivedMaxLength; > final int byteArrayInitLen = > calculateByteArrayInitLength(isLengthKnown, length, derivedMaxLength); > final int internalBufferLen = DEFAULT_BUFFER_SIZE; > try (UnsynchronizedByteArrayOutputStream baos = > UnsynchronizedByteArrayOutputStream.builder().setBufferSize(byteArrayInitLen).get()) > { > byte[] buffer = new byte[internalBufferLen]; > int totalBytes = 0, readBytes; > do { > readBytes = stream.read(buffer, 0, > Math.min(internalBufferLen, derivedLen - totalBytes)); > totalBytes += Math.max(readBytes, 0); > if (readBytes > 0) { > baos.write(buffer, 0, readBytes); > } > checkByteSizeLimit(totalBytes); > } while (totalBytes < derivedLen && readBytes > -1); > > if (BYTE_ARRAY_MAX_OVERRIDE < 0 && readBytes > -1 && > !isLengthKnown && stream.read() >= 0) { > throwRecordTruncationException(derivedMaxLength); > } > > if (checkEOFException && derivedLen != Integer.MAX_VALUE && > totalBytes < derivedLen) { > throw new EOFException("unexpected EOF - expected len: " + > derivedLen + " - actual len: " + totalBytes); > } > > return baos.toByteArray(); > } > } > > In Java 11, you’d call either stream.readNBytes() or stream.readAllBytes() > and put away with the IoUtils.toByteArray() implementation. > > - String improvements: > > Currently we have to use code like `textContent.trim().split("\n“)` to > create an array of lines and then use a for-each loop to process the > entries. Not only is the regex compiled every time, but we also keep a > string array in memory that takes at least as much space as the input > string. In java 11, we’d work on the stream returned by > textContent.trim().lines() that does neither require compiling the regex > nor keeping a full copy of the input in memory. > > - A cleaner API > > Instead of returning null (from public methods), we could return > Optional. > > - An API to clean up resources: > > Cleaner introduced in Java 9 can help reduce memory footprint with very > low overhead by automatically cleaning up unused resources in cases where > try-with-resources cannot be used. If I remember correctly, we currently > have some bug reports that might be solved by using a Cleaner, but I > wouldn’t know how to properly fix those in Java 8. > > With Java 17 we’d get: > - records: these could be used both internally and in the API and reduce > boilerplate code > - pattern matching for instanceof: This is not something one cannot live > without, but it can make the code much more concise and easier to maintain. > - the usual additions to the standard library ( > https://javaalmanac.io/jdk/18/apidiff/8/) > > > * For me, there is a better solution to optimising support for newer > Java versions while still supporting older Java versions - Multi Release > Jars [1] > > That’s like doing a fork in one code base. We currently do that for > providing a module-info.class file. But do you really want to extend that > to utility classes? IMHO that would be a maintenance nightmare. > > > * We have other Apache projects like Tika, Drill and Linkis that use POI > and some of those still apps still use Java 8 builds. We have 1000s of > other projects that depend on us - eg [2] > > > Apache Tika will require Java 11 in its upcoming version. Drill and Linkis > can stay on POI 5 and we can still provide security and important bug fixes > for that version. > > And those projects won’t suddenly stop working because the next major > release of POI switches the Java version. They can stay on 5 for the time > being. Also, I took the time and looked at the most used projects from that > list, trying to figure out what Java version they require: > > - Spring is already on Java 17 > - DbUnit is on Java 1.4 - but that version is not even supported by > current POI, and there has been no update for two years. > - Apache Tika 3 will require Java 11 > - PDI engine is Java 11 > - EasyExcel is on Java 8 > - JasperReports is on 8 but prepares switching to 11 > - Primefaces is on 8, but next version is already in RC and requires 11 > - Drools is on 11 > - OpenCms is on 8 > - WSO2 Carbon API: didn’t find information about the java version > - Silverpeas is on 11 > - HAPI FHIR: I didn’t find a reference to the Java version, but they use > Spring Boot 3 which is on 17 > - Jahia is on Java 11 > > So the majority is already on Java 11+. > > > * If you look at Stackoverflow or our mailing lists, there is a large > number of users who are using old POI versions and I think we need to avoid > making it harder for those users to upgrade. Java 8 still gets regular > security patches and depending on what you read, as many as 30% of Java > users still use Java 8 (eg [3[). > > > I think a large number will need to upgrade rather sooner than later with > practically all application servers man many other projects either are > already on 11 or even 17 or preparing the switch to Java 17. JBOSS/WildFly, > Spring, Quarkus, JOOQ, and many others. > > Even Java 6 is supported until at least end of 2027 (by Azul), while other > vendors have already dropped Java 8 (Mircosoft OpenJdk). > > Should we really dictate let those who refuse or cannot update their > systems dictate the future development of POI? > > I really think we should move on to at least 11. > > >
