Re: Java 11 for POI 5?
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
> 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 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);
>>}
>>
>>
Re: Java 11 for POI 5?
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 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
Re: poi-ooxml build times (was: Re: Java 11 for POI 5?)
That commit does not affect what I was talking about. The issue I was talking about is the * cost in compiling and generating the poi-ooxml-full code - code that does not change * the major cost in building poi-ooxml-lite - again code that rarely changes - but to build it you need to run all the poi-ooxml tests to work out which classes are needed * poi-integration which is a very slow set of tests that runs against every checked in file - including new files that were deliberately added because we need to write tests against broken files A very high proportion of the PRs and patches that we get have no tests or broken tests or even don't compile and I think a lot of this is caused by * we don't use Git and GotHub so we can't run CI against the patches * the complexity of the build discourages from users from running the tests locally * running POI tests in IntelliJ can just work but occasionally, IntelliJ will decide to do a full build including poi-ooxml-full/poi-ooxml-lite rebuild On Thursday 22 February 2024 at 17:04:15 GMT+1, Axel Howind wrote: @PJ: Hi, I just ran a poi-ooxml build and then ran the tests using the profiler. I made a little code change (r1915953), and the profiler tells me it’s beneficial. I’m still a bit sceptic, can you verify the tests run faster now? Maybe that’s something I can improve on in the coming days. Cheers, Axel > Am 21.02.2024 um 20:27 schrieb PJ Fanning : > ... > I, personally, have much more a problem with the build time wasted on > poi-ooxml-full, the complexity of poi-ooxml-lite and poi-integration - and > the fact that we can't automate our releases because of this complexity. I > have given up bringing up discussions about such items due to general lack of > engagement with the dev mailing list. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
poi-ooxml build times (was: Re: Java 11 for POI 5?)
@PJ: Hi, I just ran a poi-ooxml build and then ran the tests using the profiler. I made a little code change (r1915953), and the profiler tells me it’s beneficial. I’m still a bit sceptic, can you verify the tests run faster now? Maybe that’s something I can improve on in the coming days. Cheers, Axel > Am 21.02.2024 um 20:27 schrieb PJ Fanning : > ... > I, personally, have much more a problem with the build time wasted on > poi-ooxml-full, the complexity of poi-ooxml-lite and poi-integration - and > the fact that we can't automate our releases because of this complexity. I > have given up bringing up discussions about such items due to general lack of > engagement with the dev mailing list. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
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
Re: Java 11 for POI 5?
These are great points. > On Feb 21, 2024, at 11:27 AM, PJ Fanning wrote: > > Usually when projects dump Java 8 support, they is a strong reason. I don't > see any here. > * 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 > * I am not aware of any major Java runtime features that we need to uptake > that are not in Java 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] > * The POI build support for module-info classes is pretty stable and for me > is far from the most complicated part of the build - I, personally, have much > more a problem with the build time wasted on poi-ooxml-full, the complexity > of poi-ooxml-lite and poi-integration - and the fact that we can't automate > our releases because of this complexity. I have given up bringing up > discussions about such items due to general lack of engagement with the dev > mailing list. Let’s try again then. Let’s discuss the genesis of ooxml-lite. At Apachecon NA Oakland in 2008(?) Nick, Yegor, and I were sitting at a Hackathon table working together on POI when Jukka on the Tika project came over and said they really wanted to use POI for OOXML parsing but a 13MB jar file was just too big. Yegor thought about it and the next day OOXML-lite at 3MB was implemented. It is worth asking in these days where 6GB docker images are almost normal if our users will care about the difference in newer versions? Best, Dave > * 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] > * 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[). > > [1] https://openjdk.org/jeps/238 > [2] https://mvnrepository.com/artifact/org.apache.poi/poi-ooxml/usages > [3[ https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem > > > On 2024/02/19 23:00:32 stanton fisque wrote: >> something to consider, which kind of gathers a few of the opinions that have >> been discussed, maybe in a different light. >> >> POI is in an odd situation because it is BOTH a consumer of dependencies, >> and IS also a dependency, since it is a library and not a stand-alone >> product. >> >> as a consumer of dependencies, it should be partial to keeping pace with >> what it consumes. it would be a big dis-service if POI lagged behind on its >> dependencies and ended up getting dinged for a CERT or other security issue >> and not be able to mitigate it due to being incompatible with newer versions >> of its dependencies. >> >> though, on the other side, POI should not be too aggressive since it is >> consumed by so many other products "out in the wild". >> >> i think a java-11 requirement would suffice for now. >> >> i do not know if i am eligible (my tacit assumption is no, atm) to offer a >> +1, but if i could, i would. >> >> >> Stanton Fisque >> principal technologist >> latticeware.com >> portland, oregon >> >>> On Feb 19, 2024, at 10:54 AM, Alain FAGOT BÉAREZ >>> wrote: >>> >>> Hi, >>> >>> +1 for moving to Java 11 as minimum >>> >>> My opinion is that we should jump to the oldest LTS version each time one >>> LTS reached its end of life. This means that we would jump from 8 to 17 at >>> once... Which is also not so friendly to be done right now! >>> >>> Kind regards, >>> Alain FAGOT BÉAREZ >>> >>> >>> >>> >>> Obter o BlueMail para Android >>> >>> Em 17 de fev de 2024 09:39, em 09:39, Dominik Stadler >>> escreveu: Hi, What do others thing? We currently are at +2/-1 for moving to Java 11 minimum. Would be good if we get a more significant number of votes for this. Thanks... Dominik. On Sat, Feb 3, 2024 at 10:04 PM Axel Howind wrote: > Hi, > > for whatever reason I cannot reach both the Nabble and MarkMail archives > to check if this has been discussed before, but I think it would be a good > idea to bump the minimum Java version for POI 5 to 11. I’d also be ok (or > rather like) 17. What do you think? > > Cheers, > Axel > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > >> >> >>
Re: Java 11 for POI 5?
Usually when projects dump Java 8 support, they is a strong reason. I don't see any here. * 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 * I am not aware of any major Java runtime features that we need to uptake that are not in Java 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] * The POI build support for module-info classes is pretty stable and for me is far from the most complicated part of the build - I, personally, have much more a problem with the build time wasted on poi-ooxml-full, the complexity of poi-ooxml-lite and poi-integration - and the fact that we can't automate our releases because of this complexity. I have given up bringing up discussions about such items due to general lack of engagement with the dev mailing list. * 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] * 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[). [1] https://openjdk.org/jeps/238 [2] https://mvnrepository.com/artifact/org.apache.poi/poi-ooxml/usages [3[ https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem On 2024/02/19 23:00:32 stanton fisque wrote: > something to consider, which kind of gathers a few of the opinions that have > been discussed, maybe in a different light. > > POI is in an odd situation because it is BOTH a consumer of dependencies, and > IS also a dependency, since it is a library and not a stand-alone product. > > as a consumer of dependencies, it should be partial to keeping pace with what > it consumes. it would be a big dis-service if POI lagged behind on its > dependencies and ended up getting dinged for a CERT or other security issue > and not be able to mitigate it due to being incompatible with newer versions > of its dependencies. > > though, on the other side, POI should not be too aggressive since it is > consumed by so many other products "out in the wild". > > i think a java-11 requirement would suffice for now. > > i do not know if i am eligible (my tacit assumption is no, atm) to offer a > +1, but if i could, i would. > > > Stanton Fisque > principal technologist > latticeware.com > portland, oregon > > > On Feb 19, 2024, at 10:54 AM, Alain FAGOT BÉAREZ > > wrote: > > > > Hi, > > > > +1 for moving to Java 11 as minimum > > > > My opinion is that we should jump to the oldest LTS version each time one > > LTS reached its end of life. This means that we would jump from 8 to 17 at > > once... Which is also not so friendly to be done right now! > > > > Kind regards, > > Alain FAGOT BÉAREZ > > > > > > > > > > Obter o BlueMail para Android > > > > Em 17 de fev de 2024 09:39, em 09:39, Dominik Stadler > > escreveu: > >> Hi, > >> > >> What do others thing? > >> > >> We currently are at +2/-1 for moving to Java 11 minimum. > >> > >> Would be good if we get a more significant number of votes for this. > >> > >> Thanks... Dominik. > >> > >> > >> On Sat, Feb 3, 2024 at 10:04 PM Axel Howind wrote: > >> > >>> Hi, > >>> > >>> for whatever reason I cannot reach both the Nabble and MarkMail > >> archives > >>> to check if this has been discussed before, but I think it would be a > >> good > >>> idea to bump the minimum Java version for POI 5 to 11. I’d also be ok > >> (or > >>> rather like) 17. What do you think? > >>> > >>> Cheers, > >>> Axel > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >>> For additional commands, e-mail: dev-h...@poi.apache.org > >>> > >>> > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
something to consider, which kind of gathers a few of the opinions that have been discussed, maybe in a different light. POI is in an odd situation because it is BOTH a consumer of dependencies, and IS also a dependency, since it is a library and not a stand-alone product. as a consumer of dependencies, it should be partial to keeping pace with what it consumes. it would be a big dis-service if POI lagged behind on its dependencies and ended up getting dinged for a CERT or other security issue and not be able to mitigate it due to being incompatible with newer versions of its dependencies. though, on the other side, POI should not be too aggressive since it is consumed by so many other products "out in the wild". i think a java-11 requirement would suffice for now. i do not know if i am eligible (my tacit assumption is no, atm) to offer a +1, but if i could, i would. Stanton Fisque principal technologist latticeware.com portland, oregon > On Feb 19, 2024, at 10:54 AM, Alain FAGOT BÉAREZ wrote: > > Hi, > > +1 for moving to Java 11 as minimum > > My opinion is that we should jump to the oldest LTS version each time one LTS > reached its end of life. This means that we would jump from 8 to 17 at > once... Which is also not so friendly to be done right now! > > Kind regards, > Alain FAGOT BÉAREZ > > > > > Obter o BlueMail para Android > > Em 17 de fev de 2024 09:39, em 09:39, Dominik Stadler > escreveu: >> Hi, >> >> What do others thing? >> >> We currently are at +2/-1 for moving to Java 11 minimum. >> >> Would be good if we get a more significant number of votes for this. >> >> Thanks... Dominik. >> >> >> On Sat, Feb 3, 2024 at 10:04 PM Axel Howind wrote: >> >>> Hi, >>> >>> for whatever reason I cannot reach both the Nabble and MarkMail >> archives >>> to check if this has been discussed before, but I think it would be a >> good >>> idea to bump the minimum Java version for POI 5 to 11. I’d also be ok >> (or >>> rather like) 17. What do you think? >>> >>> Cheers, >>> Axel >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >>> For additional commands, e-mail: dev-h...@poi.apache.org >>> >>> - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
Hi, +1 for moving to Java 11 as minimum My opinion is that we should jump to the oldest LTS version each time one LTS reached its end of life. This means that we would jump from 8 to 17 at once... Which is also not so friendly to be done right now! Kind regards, Alain FAGOT BÉAREZ Obter o BlueMail para Android Em 17 de fev de 2024 09:39, em 09:39, Dominik Stadler escreveu: >Hi, > >What do others thing? > >We currently are at +2/-1 for moving to Java 11 minimum. > >Would be good if we get a more significant number of votes for this. > >Thanks... Dominik. > > >On Sat, Feb 3, 2024 at 10:04 PM Axel Howind wrote: > >> Hi, >> >> for whatever reason I cannot reach both the Nabble and MarkMail >archives >> to check if this has been discussed before, but I think it would be a >good >> idea to bump the minimum Java version for POI 5 to 11. I’d also be ok >(or >> rather like) 17. What do you think? >> >> Cheers, >> Axel >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> >>
Re: Java 11 for POI 5?
Hi, What do others thing? We currently are at +2/-1 for moving to Java 11 minimum. Would be good if we get a more significant number of votes for this. Thanks... Dominik. On Sat, Feb 3, 2024 at 10:04 PM Axel Howind wrote: > Hi, > > for whatever reason I cannot reach both the Nabble and MarkMail archives > to check if this has been discussed before, but I think it would be a good > idea to bump the minimum Java version for POI 5 to 11. I’d also be ok (or > rather like) 17. What do you think? > > Cheers, > Axel > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
Re: Java 11 for POI 5?
+1 from me of course, since I suggested the switch. > Am 03.02.2024 um 22:04 schrieb Axel Howind : > > Hi, > > for whatever reason I cannot reach both the Nabble and MarkMail archives to > check if this has been discussed before, but I think it would be a good idea > to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather > like) 17. What do you think? > > Cheers, > Axel > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
Hi, +1 from me for raising minimum Java to 11 * We can get rid of some build-complexity * Anybody who is at Java 8 should start planning upgrading by now in my opinion * expected performance improvements seen when upgrading are sometimes impressive and make for a very easy business justification if needed. * Many Apache projects moved already Regards... Dominik On Sun, Feb 4, 2024 at 9:04 PM Axel Howind wrote: > AFAIK XMLBeans is now maintained by the POI project itself, so it should > not be problematic. > > > > Am 04.02.2024 um 20:59 schrieb Dave Fisher : > > > > What version of Java is the minimum for XMLBeans? We should not forget > XMLBeans in this discussion. > > > > Best, > > Dave > > > >> On Feb 3, 2024, at 5:54 PM, Axel Howind wrote: > >> > >> No one forces users of POI to update to the latest version. Going to 11 > in POI 6 doesn't mean we > >> have to stop providing bug fixes to POI 5 from one day to the next. But > whoever is still using > >> Java 8 is now certainly used to not being able to use the newest > version of every dependency. > >> > >> Most major frameworks and many libraries now have a baseline of at > least Java 11. And many of > >> those that are still on 8 will also have to do the switch because > features from older Java > >> versions will be removed and the replacements are not yet available on > 8: > >> - finalizers (replaced by Cleaner introduced in 9) > >> - sun.misc.Unsafe (replacement depends on use case, some introduced > from 9 on) > >> > >> Current minimum Java version for some of the most used framework and > libraries: > >> Spring Framework and Spring Boot: java 17 > >> WildFly: Java 11 > >> Quarkus: Java 11 > >> Hibernate: Java 11 > >> KeyCloak: Java 17 > >> RabbitMQ: Java 11 > >> > >> Even the IDEs require more recent versions to run (but can compile > using older versions): > >> Eclipse: Java 11 (17 recommeded) > >> Netbeans: Java 11 > >> IntelliJ: Java 17 > >> > >> Even some dependencies of POI already require Java 11 in their current > version: > >> Jakarta XML bind: Java 11 is required for version 4.x > >> xmlsec: Java 11 is required for 4.x > >> > >> And some will bump the Java version for their next major release: > >> Log4j 3.x will require Java 17 > >> PDFbox 4.x will require Java 11 > >> Saxon is (hopefully?) still Java 8 compatible but not tested anymore > under Java 8 > >> > >> So staying on 8 would mean that POI will not be able to upgrade > dependencies to the latest > >> versions of some of the dependencies and possibly rely on versions that > will be unsupported in the > >> foreseeable future. > >> > >> Moving to Java 11 will make the code easier to maintain. There are a > lot of improvements in IO, > >> String handling, and collections that make the code more concise, > easier to understand, and maintain. > >> > >> > >>> Am 03.02.2024 um 22:18 schrieb PJ Fanning >: > >>> > >>> Current POI version is 5.2.5. So I presume the idea is to release a > POI 6 with Java 11 only support. I'm -1 on this. I don't see any great > advantage in only supporting Java 11. Java 8 is still widely supported by > vendors. > >>> > >>> https://endoflife.date/oracle-jdk says 6 more years of Java 8. > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind < > a...@dua3.com> wrote: > >>> > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> for whatever reason I cannot reach both the Nabble and MarkMail > archives to check if this has been discussed before, but I think it would > be a good idea to bump the minimum Java version for POI 5 to 11. I’d also > be ok (or rather like) 17. What do you think? > >>> > >>> Cheers, > >>> Axel > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >>> For additional commands, e-mail: dev-h...@poi.apache.org > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >>> For additional commands, e-mail: dev-h...@poi.apache.org > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >> For additional commands, e-mail: dev-h...@poi.apache.org > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > >
Re: Java 11 for POI 5?
A minimum Java version usually means that a project will not work with older Java versions. So if XMLBeans requires Java 8, that would mean we should be fine in having POI using at least Java 11. Even if there would be any incompatibility, we could fix these issues in XMLBeans ourselves. Since POI (which uses XMLBeans) works perfectly well on newer Java versions (I use it in Java11, Java 17 and Java 21 projects), I think it’s safe to say that XMLBeans is compatible with Java 11. > Am 04.02.2024 um 23:26 schrieb Dave Fisher : > > I certainly know since I helped negotiate it out of the Apache Attic. > > My point is that XMLBeans remains a separate codebase and build from POI. If > it requires Java 8 then POI requires Java 8. What java version does XMLBeans > require? > >> On Feb 4, 2024, at 12:04 PM, Axel Howind wrote: >> >> AFAIK XMLBeans is now maintained by the POI project itself, so it should not >> be problematic. >> >> >>> Am 04.02.2024 um 20:59 schrieb Dave Fisher : >>> >>> What version of Java is the minimum for XMLBeans? We should not forget >>> XMLBeans in this discussion. >>> >>> Best, >>> Dave >>> On Feb 3, 2024, at 5:54 PM, Axel Howind wrote: No one forces users of POI to update to the latest version. Going to 11 in POI 6 doesn't mean we have to stop providing bug fixes to POI 5 from one day to the next. But whoever is still using Java 8 is now certainly used to not being able to use the newest version of every dependency. Most major frameworks and many libraries now have a baseline of at least Java 11. And many of those that are still on 8 will also have to do the switch because features from older Java versions will be removed and the replacements are not yet available on 8: - finalizers (replaced by Cleaner introduced in 9) - sun.misc.Unsafe (replacement depends on use case, some introduced from 9 on) Current minimum Java version for some of the most used framework and libraries: Spring Framework and Spring Boot: java 17 WildFly: Java 11 Quarkus: Java 11 Hibernate: Java 11 KeyCloak: Java 17 RabbitMQ: Java 11 Even the IDEs require more recent versions to run (but can compile using older versions): Eclipse: Java 11 (17 recommeded) Netbeans: Java 11 IntelliJ: Java 17 Even some dependencies of POI already require Java 11 in their current version: Jakarta XML bind: Java 11 is required for version 4.x xmlsec: Java 11 is required for 4.x And some will bump the Java version for their next major release: Log4j 3.x will require Java 17 PDFbox 4.x will require Java 11 Saxon is (hopefully?) still Java 8 compatible but not tested anymore under Java 8 So staying on 8 would mean that POI will not be able to upgrade dependencies to the latest versions of some of the dependencies and possibly rely on versions that will be unsupported in the foreseeable future. Moving to Java 11 will make the code easier to maintain. There are a lot of improvements in IO, String handling, and collections that make the code more concise, easier to understand, and maintain. > Am 03.02.2024 um 22:18 schrieb PJ Fanning : > > Current POI version is 5.2.5. So I presume the idea is to release a POI 6 > with Java 11 only support. I'm -1 on this. I don't see any great > advantage in only supporting Java 11. Java 8 is still widely supported by > vendors. > > https://endoflife.date/oracle-jdk says 6 more years of Java 8. > > > > > > > On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind > wrote: > > > > > > Hi, > > for whatever reason I cannot reach both the Nabble and MarkMail archives > to check if this has been discussed before, but I think it would be a > good idea to bump the minimum Java version for POI 5 to 11. I’d also be > ok (or rather like) 17. What do you think? > > Cheers, > Axel > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail:
Re: Java 11 for POI 5?
I certainly know since I helped negotiate it out of the Apache Attic. My point is that XMLBeans remains a separate codebase and build from POI. If it requires Java 8 then POI requires Java 8. What java version does XMLBeans require? > On Feb 4, 2024, at 12:04 PM, Axel Howind wrote: > > AFAIK XMLBeans is now maintained by the POI project itself, so it should not > be problematic. > > >> Am 04.02.2024 um 20:59 schrieb Dave Fisher : >> >> What version of Java is the minimum for XMLBeans? We should not forget >> XMLBeans in this discussion. >> >> Best, >> Dave >> >>> On Feb 3, 2024, at 5:54 PM, Axel Howind wrote: >>> >>> No one forces users of POI to update to the latest version. Going to 11 in >>> POI 6 doesn't mean we >>> have to stop providing bug fixes to POI 5 from one day to the next. But >>> whoever is still using >>> Java 8 is now certainly used to not being able to use the newest version of >>> every dependency. >>> >>> Most major frameworks and many libraries now have a baseline of at least >>> Java 11. And many of >>> those that are still on 8 will also have to do the switch because features >>> from older Java >>> versions will be removed and the replacements are not yet available on 8: >>> - finalizers (replaced by Cleaner introduced in 9) >>> - sun.misc.Unsafe (replacement depends on use case, some introduced from 9 >>> on) >>> >>> Current minimum Java version for some of the most used framework and >>> libraries: >>> Spring Framework and Spring Boot: java 17 >>> WildFly: Java 11 >>> Quarkus: Java 11 >>> Hibernate: Java 11 >>> KeyCloak: Java 17 >>> RabbitMQ: Java 11 >>> >>> Even the IDEs require more recent versions to run (but can compile using >>> older versions): >>> Eclipse: Java 11 (17 recommeded) >>> Netbeans: Java 11 >>> IntelliJ: Java 17 >>> >>> Even some dependencies of POI already require Java 11 in their current >>> version: >>> Jakarta XML bind: Java 11 is required for version 4.x >>> xmlsec: Java 11 is required for 4.x >>> >>> And some will bump the Java version for their next major release: >>> Log4j 3.x will require Java 17 >>> PDFbox 4.x will require Java 11 >>> Saxon is (hopefully?) still Java 8 compatible but not tested anymore under >>> Java 8 >>> >>> So staying on 8 would mean that POI will not be able to upgrade >>> dependencies to the latest >>> versions of some of the dependencies and possibly rely on versions that >>> will be unsupported in the >>> foreseeable future. >>> >>> Moving to Java 11 will make the code easier to maintain. There are a lot of >>> improvements in IO, >>> String handling, and collections that make the code more concise, easier to >>> understand, and maintain. >>> >>> Am 03.02.2024 um 22:18 schrieb PJ Fanning : Current POI version is 5.2.5. So I presume the idea is to release a POI 6 with Java 11 only support. I'm -1 on this. I don't see any great advantage in only supporting Java 11. Java 8 is still widely supported by vendors. https://endoflife.date/oracle-jdk says 6 more years of Java 8. On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind wrote: Hi, for whatever reason I cannot reach both the Nabble and MarkMail archives to check if this has been discussed before, but I think it would be a good idea to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather like) 17. What do you think? Cheers, Axel - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >>> For additional commands, e-mail: dev-h...@poi.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
AFAIK XMLBeans is now maintained by the POI project itself, so it should not be problematic. > Am 04.02.2024 um 20:59 schrieb Dave Fisher : > > What version of Java is the minimum for XMLBeans? We should not forget > XMLBeans in this discussion. > > Best, > Dave > >> On Feb 3, 2024, at 5:54 PM, Axel Howind wrote: >> >> No one forces users of POI to update to the latest version. Going to 11 in >> POI 6 doesn't mean we >> have to stop providing bug fixes to POI 5 from one day to the next. But >> whoever is still using >> Java 8 is now certainly used to not being able to use the newest version of >> every dependency. >> >> Most major frameworks and many libraries now have a baseline of at least >> Java 11. And many of >> those that are still on 8 will also have to do the switch because features >> from older Java >> versions will be removed and the replacements are not yet available on 8: >> - finalizers (replaced by Cleaner introduced in 9) >> - sun.misc.Unsafe (replacement depends on use case, some introduced from 9 >> on) >> >> Current minimum Java version for some of the most used framework and >> libraries: >> Spring Framework and Spring Boot: java 17 >> WildFly: Java 11 >> Quarkus: Java 11 >> Hibernate: Java 11 >> KeyCloak: Java 17 >> RabbitMQ: Java 11 >> >> Even the IDEs require more recent versions to run (but can compile using >> older versions): >> Eclipse: Java 11 (17 recommeded) >> Netbeans: Java 11 >> IntelliJ: Java 17 >> >> Even some dependencies of POI already require Java 11 in their current >> version: >> Jakarta XML bind: Java 11 is required for version 4.x >> xmlsec: Java 11 is required for 4.x >> >> And some will bump the Java version for their next major release: >> Log4j 3.x will require Java 17 >> PDFbox 4.x will require Java 11 >> Saxon is (hopefully?) still Java 8 compatible but not tested anymore under >> Java 8 >> >> So staying on 8 would mean that POI will not be able to upgrade dependencies >> to the latest >> versions of some of the dependencies and possibly rely on versions that will >> be unsupported in the >> foreseeable future. >> >> Moving to Java 11 will make the code easier to maintain. There are a lot of >> improvements in IO, >> String handling, and collections that make the code more concise, easier to >> understand, and maintain. >> >> >>> Am 03.02.2024 um 22:18 schrieb PJ Fanning : >>> >>> Current POI version is 5.2.5. So I presume the idea is to release a POI 6 >>> with Java 11 only support. I'm -1 on this. I don't see any great advantage >>> in only supporting Java 11. Java 8 is still widely supported by vendors. >>> >>> https://endoflife.date/oracle-jdk says 6 more years of Java 8. >>> >>> >>> >>> >>> >>> >>> On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind >>> wrote: >>> >>> >>> >>> >>> >>> Hi, >>> >>> for whatever reason I cannot reach both the Nabble and MarkMail archives to >>> check if this has been discussed before, but I think it would be a good >>> idea to bump the minimum Java version for POI 5 to 11. I’d also be ok (or >>> rather like) 17. What do you think? >>> >>> Cheers, >>> Axel >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >>> For additional commands, e-mail: dev-h...@poi.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >>> For additional commands, e-mail: dev-h...@poi.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org >
Re: Java 11 for POI 5?
What version of Java is the minimum for XMLBeans? We should not forget XMLBeans in this discussion. Best, Dave > On Feb 3, 2024, at 5:54 PM, Axel Howind wrote: > > No one forces users of POI to update to the latest version. Going to 11 in > POI 6 doesn't mean we > have to stop providing bug fixes to POI 5 from one day to the next. But > whoever is still using > Java 8 is now certainly used to not being able to use the newest version of > every dependency. > > Most major frameworks and many libraries now have a baseline of at least Java > 11. And many of > those that are still on 8 will also have to do the switch because features > from older Java > versions will be removed and the replacements are not yet available on 8: > - finalizers (replaced by Cleaner introduced in 9) > - sun.misc.Unsafe (replacement depends on use case, some introduced from 9 on) > > Current minimum Java version for some of the most used framework and > libraries: > Spring Framework and Spring Boot: java 17 > WildFly: Java 11 > Quarkus: Java 11 > Hibernate: Java 11 > KeyCloak: Java 17 > RabbitMQ: Java 11 > > Even the IDEs require more recent versions to run (but can compile using > older versions): > Eclipse: Java 11 (17 recommeded) > Netbeans: Java 11 > IntelliJ: Java 17 > > Even some dependencies of POI already require Java 11 in their current > version: > Jakarta XML bind: Java 11 is required for version 4.x > xmlsec: Java 11 is required for 4.x > > And some will bump the Java version for their next major release: > Log4j 3.x will require Java 17 > PDFbox 4.x will require Java 11 > Saxon is (hopefully?) still Java 8 compatible but not tested anymore under > Java 8 > > So staying on 8 would mean that POI will not be able to upgrade dependencies > to the latest > versions of some of the dependencies and possibly rely on versions that will > be unsupported in the > foreseeable future. > > Moving to Java 11 will make the code easier to maintain. There are a lot of > improvements in IO, > String handling, and collections that make the code more concise, easier to > understand, and maintain. > > >> Am 03.02.2024 um 22:18 schrieb PJ Fanning : >> >> Current POI version is 5.2.5. So I presume the idea is to release a POI 6 >> with Java 11 only support. I'm -1 on this. I don't see any great advantage >> in only supporting Java 11. Java 8 is still widely supported by vendors. >> >> https://endoflife.date/oracle-jdk says 6 more years of Java 8. >> >> >> >> >> >> >> On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind >> wrote: >> >> >> >> >> >> Hi, >> >> for whatever reason I cannot reach both the Nabble and MarkMail archives to >> check if this has been discussed before, but I think it would be a good idea >> to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather >> like) 17. What do you think? >> >> Cheers, >> Axel >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
No one forces users of POI to update to the latest version. Going to 11 in POI 6 doesn't mean we have to stop providing bug fixes to POI 5 from one day to the next. But whoever is still using Java 8 is now certainly used to not being able to use the newest version of every dependency. Most major frameworks and many libraries now have a baseline of at least Java 11. And many of those that are still on 8 will also have to do the switch because features from older Java versions will be removed and the replacements are not yet available on 8: - finalizers (replaced by Cleaner introduced in 9) - sun.misc.Unsafe (replacement depends on use case, some introduced from 9 on) Current minimum Java version for some of the most used framework and libraries: Spring Framework and Spring Boot: java 17 WildFly: Java 11 Quarkus: Java 11 Hibernate: Java 11 KeyCloak: Java 17 RabbitMQ: Java 11 Even the IDEs require more recent versions to run (but can compile using older versions): Eclipse: Java 11 (17 recommeded) Netbeans: Java 11 IntelliJ: Java 17 Even some dependencies of POI already require Java 11 in their current version: Jakarta XML bind: Java 11 is required for version 4.x xmlsec: Java 11 is required for 4.x And some will bump the Java version for their next major release: Log4j 3.x will require Java 17 PDFbox 4.x will require Java 11 Saxon is (hopefully?) still Java 8 compatible but not tested anymore under Java 8 So staying on 8 would mean that POI will not be able to upgrade dependencies to the latest versions of some of the dependencies and possibly rely on versions that will be unsupported in the foreseeable future. Moving to Java 11 will make the code easier to maintain. There are a lot of improvements in IO, String handling, and collections that make the code more concise, easier to understand, and maintain. > Am 03.02.2024 um 22:18 schrieb PJ Fanning : > > Current POI version is 5.2.5. So I presume the idea is to release a POI 6 > with Java 11 only support. I'm -1 on this. I don't see any great advantage in > only supporting Java 11. Java 8 is still widely supported by vendors. > > https://endoflife.date/oracle-jdk says 6 more years of Java 8. > > > > > > > On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind > wrote: > > > > > > Hi, > > for whatever reason I cannot reach both the Nabble and MarkMail archives to > check if this has been discussed before, but I think it would be a good idea > to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather > like) 17. What do you think? > > Cheers, > Axel > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
that may very well be, BUT, many commercial shops are migrating apps from 8 and 11 where able because the blood money for EoL java is starting to be a tax they don't want to pay if possible. just like when we had to bite the bullet with 1.1, 1.5 and 1.8, i recommend at the very least, moving up to 11, but seriously urge for 17. TBH if people need 8 support, they can stick with 5.x if need be until they need to move up. something to consider, how many projects that are going to target the bleeding edge version of POI really need java 8 support? my feeling is that number is so small to be trivial. and if a project has the available resources to follow the newest version of POI, they probably have the resources to upgrade their app to a newer version of java. Stanton Fisque principal technologist latticeware.com portland, oregon > On Feb 3, 2024, at 13:18 PM, PJ Fanning wrote: > > Current POI version is 5.2.5. So I presume the idea is to release a POI 6 > with Java 11 only support. I'm -1 on this. I don't see any great advantage in > only supporting Java 11. Java 8 is still widely supported by vendors. > > https://endoflife.date/oracle-jdk says 6 more years of Java 8. > > > > > > > On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind > wrote: > > > > > > Hi, > > for whatever reason I cannot reach both the Nabble and MarkMail archives to > check if this has been discussed before, but I think it would be a good idea > to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather > like) 17. What do you think? > > Cheers, > Axel > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Java 11 for POI 5?
Current POI version is 5.2.5. So I presume the idea is to release a POI 6 with Java 11 only support. I'm -1 on this. I don't see any great advantage in only supporting Java 11. Java 8 is still widely supported by vendors. https://endoflife.date/oracle-jdk says 6 more years of Java 8. On Saturday 3 February 2024 at 22:04:26 GMT+1, Axel Howind wrote: Hi, for whatever reason I cannot reach both the Nabble and MarkMail archives to check if this has been discussed before, but I think it would be a good idea to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather like) 17. What do you think? Cheers, Axel - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Java 11 for POI 5?
Hi, for whatever reason I cannot reach both the Nabble and MarkMail archives to check if this has been discussed before, but I think it would be a good idea to bump the minimum Java version for POI 5 to 11. I’d also be ok (or rather like) 17. What do you think? Cheers, Axel - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
