[
https://issues.apache.org/jira/browse/TIKA-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison updated TIKA-3735:
------------------------------
Description:
This follows on from discussion we had on the user/dev list for when we want to
require Java 11. I think the consensus was: wait until we have to.
The following libraries require > Java 8 at the moment. I don't think updating
any of these is critical, but I do want to document where we're stuck.
We can modify/edit this list as necessary:
* Apache OpenNLP 2.0.0 requires Java 11.
* DL4J 1.0.0-M2.1 - datavec-data-image-1.0.0-M2.1.jar requires Java 11
* Lucene 9.x – used in tika-eval
* icu4j – we can't upgrade past 62.2 (April 2019) because that is the latest
version that is compatible with Lucene 8.11.1
([https://github.com/apache/tika/pull/587])
* mime4j – the last 2 (or three?) releases have been accidentally built with
Java 9 without the correct release=8. This should be fixed in the next release.
* Fakeload
*
[checkstyle|https://mail.google.com/mail/u/0/#label/lists%2Ftika/WhctKKXXHvjnJRRdBSwLbKkDkXQtRnWGDhblVMQQZhjsDGrFpRMRQJJrZSdskrNCqcmTtjL]
* errorprone requires Java 11 for the build (doesn't mean we can't target 8)
Bug fixes
* This is a profoundly stupid bug in jdk8 but not in jdk 11:
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8213470]. I ran into
this when trying to upgrade mime4j. The problem is that DateTimeFormatter's
withZone() does a blanket override in jdk8 of the timezone no matter if an
offset was parsed in the input string. JDK11 respects the offset correctly.
Input: "Tue, 9 Jun 2009 23:58:45 -0400", WRONG JDK 8
output:"2009-06-09T23:58:45Z" CORRECT JDK 11 output: "2009-06-10T03:58:45Z"
was:
This follows on from discussion we had on the user/dev list for when we want to
require Java 11. I think the consensus was: wait until we have to.
The following libraries require > Java 8 at the moment. I don't think updating
any of these is critical, but I do want to document where we're stuck.
We can modify/edit this list as necessary:
* Apache OpenNLP 2.0.0 requires Java 11.
* DL4J 1.0.0-M2.1 - datavec-data-image-1.0.0-M2.1.jar requires Java 11
* Lucene 9.x -- used in tika-eval
* icu4j -- we can't upgrade past 62.2 (April 2019) because that is the latest
version that is compatible with Lucene 8.11.1
(https://github.com/apache/tika/pull/587)
* mime4j -- the last 2 (or three?) releases have been accidentally built with
Java 9 without the correct release=8. This should be fixed in the next release.
* Fakeload
*
[checkstyle|https://mail.google.com/mail/u/0/#label/lists%2Ftika/WhctKKXXHvjnJRRdBSwLbKkDkXQtRnWGDhblVMQQZhjsDGrFpRMRQJJrZSdskrNCqcmTtjL]
* errorprone requires Java 11 for the build (doesn't mean we can't target 8)
> Require Java 11 for 2.x at some point
> -------------------------------------
>
> Key: TIKA-3735
> URL: https://issues.apache.org/jira/browse/TIKA-3735
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> This follows on from discussion we had on the user/dev list for when we want
> to require Java 11. I think the consensus was: wait until we have to.
> The following libraries require > Java 8 at the moment. I don't think
> updating any of these is critical, but I do want to document where we're
> stuck.
> We can modify/edit this list as necessary:
> * Apache OpenNLP 2.0.0 requires Java 11.
> * DL4J 1.0.0-M2.1 - datavec-data-image-1.0.0-M2.1.jar requires Java 11
> * Lucene 9.x – used in tika-eval
> * icu4j – we can't upgrade past 62.2 (April 2019) because that is the latest
> version that is compatible with Lucene 8.11.1
> ([https://github.com/apache/tika/pull/587])
> * mime4j – the last 2 (or three?) releases have been accidentally built with
> Java 9 without the correct release=8. This should be fixed in the next
> release.
> * Fakeload
> *
> [checkstyle|https://mail.google.com/mail/u/0/#label/lists%2Ftika/WhctKKXXHvjnJRRdBSwLbKkDkXQtRnWGDhblVMQQZhjsDGrFpRMRQJJrZSdskrNCqcmTtjL]
> * errorprone requires Java 11 for the build (doesn't mean we can't target 8)
> Bug fixes
> * This is a profoundly stupid bug in jdk8 but not in jdk 11:
> [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8213470]. I ran
> into this when trying to upgrade mime4j. The problem is that
> DateTimeFormatter's withZone() does a blanket override in jdk8 of the
> timezone no matter if an offset was parsed in the input string. JDK11
> respects the offset correctly. Input: "Tue, 9 Jun 2009 23:58:45 -0400",
> WRONG JDK 8 output:"2009-06-09T23:58:45Z" CORRECT JDK 11 output:
> "2009-06-10T03:58:45Z"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
