I am still using it with Java 8. I am planning to move to Java 11, of course, but I keep putting it off. One of the other libraries I am using has problems with Java 11 and I am trying to figure out how to fix that.
-Ralph Johnson On Sun, Feb 25, 2024 at 7:09 AM Dominik Stadler <[email protected]> wrote: > [image: Boxbe] <https://www.boxbe.com/overview> This message is eligible > for Automatic Cleanup! ([email protected]) Add cleanup rule > <https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DqLkQtRN2h%252FTJ17N0s3R07qNdjSs8XjyyfEC0loaYg3o%253D%26token%3DQSq8Qkz22gY%252FDm3153JujGsxzxhdQj8VePJNsPH5jx%252B2ad6z4G1KTX2D5qXQG9o%252BHE47DM4kptb%252FPY1FHYTsa3UzLhdan6C2bzHC6A0IiyGy5ldzVraqSPJzduKzo90ShKEZooogx7kbQhQvtJl%252Fbm4XEUbE9dZT&tc_serial=59958998330&tc_rand=1756539120&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001&;> > | More info > <http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=59958998330&tc_rand=1756539120&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001&;> > 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 <[email protected]> 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. > > > > > > >
