Hello, We do use POI with Java 8. We deploy to customer environments where we don’t have a strong say in the runtime version. We do NOT think POI needs to support Java 8 in the next version.
Cheers, Marius > On Feb 25, 2024, at 08:03, Dominik Stadler <dominik.stad...@gmx.at.invalid> > wrote: > > 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. >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
