You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by kiwiwings <ki...@apache.org> on 2017/07/09 12:29:10 UTC
Re: Java 6 support
It has been a while that we've discussed this topic ... or at least I
couldn't find another more recent/decent thread ... [1]
How about switching to Java 7 now?
If we'd do, will we change to version 4 then?
Andi
[1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
--
View this message in context: http://apache-poi.1045710.n5.nabble.com/Java-6-support-tp5721373p5728102.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Java 6 support
Posted by Andreas Beeker <ki...@apache.org>.
> Andi just tried to use more generics in some places and this showed a
> problem either in Java 9 or Java 6 and thus he reverted this change again.
AFAIK this also happened when I've refactored the SL Common interfaces, but I've forgotten about it :S
This is a bug in Java 6 ... there are a few entries in stackoverflow (I haven't searched for the jdk bug entry ...):
https://stackoverflow.com/questions/9937422
https://stackoverflow.com/questions/9314046
Andi
Re: Java 6 support
Posted by Dominik Stadler <do...@gmx.at>.
Hi,
POI is already fully working on Java 9 (at least according to our
unit-tests at https://builds.apache.org/view/P/view/POI/job/POI-DSL-1.9/,
and I once ran the full regression suite with some pre-release of Java 9 to
check for additional problems.), there are some module-adjustment that are
necessary during compilation/runtime, but this is to be expected with the
Java 9 module system as far as I see.
Andi just tried to use more generics in some places and this showed a
problem either in Java 9 or Java 6 and thus he reverted this change again.
Dominik.
On Sun, Jul 9, 2017 at 7:13 PM, pj.fanning <fa...@yahoo.com> wrote:
> I favour more regular non-beta releases generally and like the idea of a
> 4.0
> release.
> I'm pretty neutral on the JRE version support. My employers mandate JRE 1.8
> usage and I think, for security reasons, this is the right approach.
> My 2 cents is that we could continue to support a 3.x branch and backport
> security fixes and fixes that would be generally useful to a wide
> community.
> As part of a possible 4.0 release, we should review the deprecated code to
> try and prune as much as possible.
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.
> nabble.com/Java-6-support-tp5721373p5728121.html
> Sent from the POI - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
Re: Java 6 support
Posted by Javen O'Neal <on...@apache.org>.
> My 2 cents is that we could continue to support a 3.x branch and backport
security fixes and fixes that would be generally useful to a wide community.
I could get behind back porting security fixes since they're fairly
infrequent and small.
Fully maintaining a branch would get tricky as the code bases diverge and
merge. We already have a bandwidth problem with 1 code base. I'd rather
spend my energy on improving what we have than keeping two trees in sync.
Furthermore I think the audience for a 3.x branch is fairly small. Users
stuck on Java 6 (read: large companies) are less likely to upgrade to new
versions of POI, especially as we keep evolving the API.
> As part of a possible 4.0 release, we should review the deprecated code to
try and prune as much as possible.
Agreed. With all the enum enhancements, CellType is one that's so engrained
on our quick guide, on mailing lists, stack overflow questions and answers,
and elsewhere that Nick suggested we wait til 4.0 to change
Cell.getCellType() to return a CellType enum. Most of the rest of the enums
added in the last few releases are less heavily found in 3rd party code
that it was safe to do:
1. Add getXEnum() and deprecate getX()
2. Wait 2 releases
3. Change getX() to return an enum, deprecate getXEnum()
4. Wait 2 releases
5. Delete getXEnum().
See Bug 59836 https://bz.apache.org/bugzilla/show_bug.cgi?id=59836
On Jul 9, 2017 19:13, "pj.fanning" <fa...@yahoo.com> wrote:
I favour more regular non-beta releases generally and like the idea of a 4.0
release.
I'm pretty neutral on the JRE version support. My employers mandate JRE 1.8
usage and I think, for security reasons, this is the right approach.
My 2 cents is that we could continue to support a 3.x branch and backport
security fixes and fixes that would be generally useful to a wide community.
As part of a possible 4.0 release, we should review the deprecated code to
try and prune as much as possible.
--
View this message in context: http://apache-poi.1045710.n5.
nabble.com/Java-6-support-tp5721373p5728121.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Java 6 support
Posted by "pj.fanning" <fa...@yahoo.com>.
I favour more regular non-beta releases generally and like the idea of a 4.0
release.
I'm pretty neutral on the JRE version support. My employers mandate JRE 1.8
usage and I think, for security reasons, this is the right approach.
My 2 cents is that we could continue to support a 3.x branch and backport
security fixes and fixes that would be generally useful to a wide community.
As part of a possible 4.0 release, we should review the deprecated code to
try and prune as much as possible.
--
View this message in context: http://apache-poi.1045710.n5.nabble.com/Java-6-support-tp5721373p5728121.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Java 6 support
Posted by Javen O'Neal <on...@apache.org>.
Then let's kick XMLBeans to POI 5.0 and drop Java 6 ASAP if it's preventing
Java 9 support.
Java 9 is just around the corner (July 27).
We should aim to support Java 9 the day it's released so we're not a reason
for other software projects to delay Java 9 adoption.
Have we addressed the open issues with POI 3.17 beta 1 that we'd be
comfortable with a 3.17 final release?
We could make 3.17 final and 4.0 nearly identical, released the same day or
a few days apart, with the only difference being dropping Java 6
compatibility and adding Java 9 compatibility.
On Jul 9, 2017 5:47 PM, "Andreas Beeker" <ki...@apache.org> wrote:
> +1 for switching now or after POI 3.17 ... if we will do a 3.17 final
> soonish.
>
> I'm actually bringing this up, as I was facing again problems with
> generics bugs in Java 6 and independently had a devops discussion with
> fluxo yesterday, questioning me/us why we are still on Java 6 level.
>
> > If we're talking about POI 4.0, we should also think about replacing
> > XMLBeans, since that can't be done gradually like refactoring the code to
> > use Java 7 language features.
>
> Switching to Java 7 is probably just a declarative issue in the beginning
> and we gradually upgrade the source in the releases afterwards - I don't
> see a XmlBeans replacement coming so soon and we shouldn't pack to many
> changes in version 4.0. Furthermore I don't think replacing XMLBeans can be
> done gradually - at least this should happen module-wise in my point of
> view.
>
> I also wouldn't spend any time to think about Java 6 mitigations - as the
> long term support is running out for most customers - at least that's what
> happened to my last project in a quite update-reluctant company with a IBM
> java environment.
>
> Andi
>
>
>
Re: Java 6 support
Posted by Andreas Beeker <ki...@apache.org>.
+1 for switching now or after POI 3.17 ... if we will do a 3.17 final soonish.
I'm actually bringing this up, as I was facing again problems with generics bugs in Java 6 and independently had a devops discussion with fluxo yesterday, questioning me/us why we are still on Java 6 level.
> If we're talking about POI 4.0, we should also think about replacing
> XMLBeans, since that can't be done gradually like refactoring the code to
> use Java 7 language features.
Switching to Java 7 is probably just a declarative issue in the beginning and we gradually upgrade the source in the releases afterwards - I don't see a XmlBeans replacement coming so soon and we shouldn't pack to many changes in version 4.0. Furthermore I don't think replacing XMLBeans can be done gradually - at least this should happen module-wise in my point of view.
I also wouldn't spend any time to think about Java 6 mitigations - as the long term support is running out for most customers - at least that's what happened to my last project in a quite update-reluctant company with a IBM java environment.
Andi
Re: Java 6 support
Posted by Javen O'Neal <on...@apache.org>.
The Android dev team have been making progress on Java 8 support, including
3rd party libraries, though currently still is a subset of the full Java 8
language specification.
There will be more problems with Android API level <=23 (Marshmallow and
older).
https://developer.android.com/studio/write/java8-support.html
On Jul 9, 2017 16:29, "Dominik Stadler" <do...@gmx.at> wrote:
> Hi,
>
> +1 for Java 7 in POI 4 after 3.17 is out. And I for not investing too much
> in backwards compatibility, people on Java 6 likely still run POI 3.9
> anyway.
>
> I'm -1 on Java 8, as 7 is still needed for Android AFAIK and we get a
> number of requests in that area lately.
>
> Dominik
>
> On Jul 9, 2017 16:10, "Javen O'Neal" <on...@apache.org> wrote:
>
> > (writing an iterator in Java is particularly painful).
> We could also leapfrog Java 7 and go straight to Java 8 with support for
> streams and lambdas.
>
> And yes, it's a can of worms to try to compile Java 7/8 source to Java 6
> bytecode. It shouldn't be, as that's one of the glorious things about
> intermediate code, and somehow Kotlin and other languages managed to
> compile to Java 6 bytecode...
> https://stackoverflow.com/questions/22610400/a-program-
> made-with-java-8-can-be-run-on-java-7
>
> On Jul 9, 2017 15:48, "Javen O'Neal" <on...@apache.org> wrote:
>
> +1
>
> I'm in favor of dropping Java 6 support. If users still need to run new
> versions of POI on old JVMs, they should be able to cross-compile, though
> it may require some extra tools on their end to modify the bytecode to be
> compatible with and old JVM.
>
> If we can figure out a way to maintain binary compatibility with Java 6
> while rewriting our code with features from Java 7 (diamond operator for
> inferred generic type, try-with-resources, Unicode literals), then it's a
> no-brainer.
>
> If cross compilation doesn't work, I was toying with the idea of rewriting
> parts of the code in Kotlin, Scala, or other static JVM language that
> maintains Java 6 compatibility while providing a less verbose language to
> write code in (writing an iterator in Java is particularly painful).
>
> If we're talking about POI 4.0, we should also think about replacing
> XMLBeans, since that can't be done gradually like refactoring the code to
> use Java 7 language features.
>
> Either before or after we replace XMLBeans, it'd be worthwhile to fully
> read files into POJOs so we don't have to keep an XMLDOM open. This is why
> we struggle with RAM and CPU performance.
>
> I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
> (assuming we want that), but it's worth discussing as we look at the
> roadmap of dependent tasks to move forward.
>
> Of course, if we're not ready to embark on replacing XMLBeans and
> de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
> XMLBeans and the XMLDOM in POI 5 (or 6).
>
> On Jul 9, 2017 14:29, "kiwiwings" <ki...@apache.org> wrote:
>
> It has been a while that we've discussed this topic ... or at least I
> couldn't find another more recent/decent thread ... [1]
>
> How about switching to Java 7 now?
> If we'd do, will we change to version 4 then?
>
> Andi
>
>
>
> [1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.n
> abble.com/Java-6-support-tp5721373p5728102.html
> Sent from the POI - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
Re: Java 6 support
Posted by Dominik Stadler <do...@gmx.at>.
Hi,
+1 for Java 7 in POI 4 after 3.17 is out. And I for not investing too much
in backwards compatibility, people on Java 6 likely still run POI 3.9
anyway.
I'm -1 on Java 8, as 7 is still needed for Android AFAIK and we get a
number of requests in that area lately.
Dominik
On Jul 9, 2017 16:10, "Javen O'Neal" <on...@apache.org> wrote:
> (writing an iterator in Java is particularly painful).
We could also leapfrog Java 7 and go straight to Java 8 with support for
streams and lambdas.
And yes, it's a can of worms to try to compile Java 7/8 source to Java 6
bytecode. It shouldn't be, as that's one of the glorious things about
intermediate code, and somehow Kotlin and other languages managed to
compile to Java 6 bytecode...
https://stackoverflow.com/questions/22610400/a-program-
made-with-java-8-can-be-run-on-java-7
On Jul 9, 2017 15:48, "Javen O'Neal" <on...@apache.org> wrote:
+1
I'm in favor of dropping Java 6 support. If users still need to run new
versions of POI on old JVMs, they should be able to cross-compile, though
it may require some extra tools on their end to modify the bytecode to be
compatible with and old JVM.
If we can figure out a way to maintain binary compatibility with Java 6
while rewriting our code with features from Java 7 (diamond operator for
inferred generic type, try-with-resources, Unicode literals), then it's a
no-brainer.
If cross compilation doesn't work, I was toying with the idea of rewriting
parts of the code in Kotlin, Scala, or other static JVM language that
maintains Java 6 compatibility while providing a less verbose language to
write code in (writing an iterator in Java is particularly painful).
If we're talking about POI 4.0, we should also think about replacing
XMLBeans, since that can't be done gradually like refactoring the code to
use Java 7 language features.
Either before or after we replace XMLBeans, it'd be worthwhile to fully
read files into POJOs so we don't have to keep an XMLDOM open. This is why
we struggle with RAM and CPU performance.
I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
(assuming we want that), but it's worth discussing as we look at the
roadmap of dependent tasks to move forward.
Of course, if we're not ready to embark on replacing XMLBeans and
de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
XMLBeans and the XMLDOM in POI 5 (or 6).
On Jul 9, 2017 14:29, "kiwiwings" <ki...@apache.org> wrote:
It has been a while that we've discussed this topic ... or at least I
couldn't find another more recent/decent thread ... [1]
How about switching to Java 7 now?
If we'd do, will we change to version 4 then?
Andi
[1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
--
View this message in context: http://apache-poi.1045710.n5.n
abble.com/Java-6-support-tp5721373p5728102.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Java 6 support
Posted by Javen O'Neal <on...@apache.org>.
> (writing an iterator in Java is particularly painful).
We could also leapfrog Java 7 and go straight to Java 8 with support for
streams and lambdas.
And yes, it's a can of worms to try to compile Java 7/8 source to Java 6
bytecode. It shouldn't be, as that's one of the glorious things about
intermediate code, and somehow Kotlin and other languages managed to
compile to Java 6 bytecode...
https://stackoverflow.com/questions/22610400/a-program-made-with-java-8-can-be-run-on-java-7
On Jul 9, 2017 15:48, "Javen O'Neal" <on...@apache.org> wrote:
+1
I'm in favor of dropping Java 6 support. If users still need to run new
versions of POI on old JVMs, they should be able to cross-compile, though
it may require some extra tools on their end to modify the bytecode to be
compatible with and old JVM.
If we can figure out a way to maintain binary compatibility with Java 6
while rewriting our code with features from Java 7 (diamond operator for
inferred generic type, try-with-resources, Unicode literals), then it's a
no-brainer.
If cross compilation doesn't work, I was toying with the idea of rewriting
parts of the code in Kotlin, Scala, or other static JVM language that
maintains Java 6 compatibility while providing a less verbose language to
write code in (writing an iterator in Java is particularly painful).
If we're talking about POI 4.0, we should also think about replacing
XMLBeans, since that can't be done gradually like refactoring the code to
use Java 7 language features.
Either before or after we replace XMLBeans, it'd be worthwhile to fully
read files into POJOs so we don't have to keep an XMLDOM open. This is why
we struggle with RAM and CPU performance.
I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
(assuming we want that), but it's worth discussing as we look at the
roadmap of dependent tasks to move forward.
Of course, if we're not ready to embark on replacing XMLBeans and
de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
XMLBeans and the XMLDOM in POI 5 (or 6).
On Jul 9, 2017 14:29, "kiwiwings" <ki...@apache.org> wrote:
It has been a while that we've discussed this topic ... or at least I
couldn't find another more recent/decent thread ... [1]
How about switching to Java 7 now?
If we'd do, will we change to version 4 then?
Andi
[1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
--
View this message in context: http://apache-poi.1045710.n5.n
abble.com/Java-6-support-tp5721373p5728102.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Java 6 support
Posted by Javen O'Neal <on...@apache.org>.
+1
I'm in favor of dropping Java 6 support. If users still need to run new
versions of POI on old JVMs, they should be able to cross-compile, though
it may require some extra tools on their end to modify the bytecode to be
compatible with and old JVM.
If we can figure out a way to maintain binary compatibility with Java 6
while rewriting our code with features from Java 7 (diamond operator for
inferred generic type, try-with-resources, Unicode literals), then it's a
no-brainer.
If cross compilation doesn't work, I was toying with the idea of rewriting
parts of the code in Kotlin, Scala, or other static JVM language that
maintains Java 6 compatibility while providing a less verbose language to
write code in (writing an iterator in Java is particularly painful).
If we're talking about POI 4.0, we should also think about replacing
XMLBeans, since that can't be done gradually like refactoring the code to
use Java 7 language features.
Either before or after we replace XMLBeans, it'd be worthwhile to fully
read files into POJOs so we don't have to keep an XMLDOM open. This is why
we struggle with RAM and CPU performance.
I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
(assuming we want that), but it's worth discussing as we look at the
roadmap of dependent tasks to move forward.
Of course, if we're not ready to embark on replacing XMLBeans and
de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
XMLBeans and the XMLDOM in POI 5 (or 6).
On Jul 9, 2017 14:29, "kiwiwings" <ki...@apache.org> wrote:
It has been a while that we've discussed this topic ... or at least I
couldn't find another more recent/decent thread ... [1]
How about switching to Java 7 now?
If we'd do, will we change to version 4 then?
Andi
[1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
--
View this message in context: http://apache-poi.1045710.n5.
nabble.com/Java-6-support-tp5721373p5728102.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org