Hi folks, forget Java 11, its neither here nor there.
I recommend a braver leap. Time for a version hike that we can stay with for years to come. Java 17 is Long Term Service, that's important. But, just as important, it is a well-balanced, mature release where you won't (well, hardly) find yourself sighing after some new feature. Go for 17! You won't regret it. All the best, DaveLaw > Andreas Reichel <[email protected]> hat am 25.02.2024 23:45 CET > geschrieben: > > > Greetings All! > > From our point of view the time of Java 8 is over: > > 1) more and more libraries and gradle plugins require Java 11 for the > latest > 2) POI 5 is at a very great spot, stable and robust with low(er) issue > frequency compared to the years before > > So anyone who must stay with Java 8 can stay with latest POI 5 (not > missing out) while the team can focus on a Java 11 update and > migration. > > Although Java 17 would be too far to jump right now. Lots clients just > decided to run Java 11 and also JavaDoc format has changed. > It may be wise to require Java 11 for 3-5 years and then jump to Java > 21 directly. > > Cheers > Andreas > > On Sun, 2024-02-25 at 14:01 +0100, Dominik Stadler 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 <[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(byteArr > > > ayInitLen).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: [email protected] For additional commands, e-mail: [email protected]
