Java 6 support

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Java 6 support

Javen O'Neal
Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
released Java 7 in 2011 and ended support in 2015. Java 8 was released
in 2014.

There are a few language features introduced in Java 7 that would be
nice to use in POI. This would mean asking everyone to move off of
Java 6, but seems justifiable.

I'd really like to use some of the Java 8 features, but usage of Java
7 is too prevalent today.

A few Java 7 features that would be nice to use in the POI library:
* switch statements on strings
* improved generics type inference (diamond operator)
* try-with-resources
* try/multi-catch

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

kiwiwings
I'm ambivalent on this issue, as see our web sphere environment (at my $DAYJOB at a big insurance company) languish around on IBM JDK 1.5 / 1.6 ... and I guess that's a common problem.
On the other hand the projects usually still stick with POI 3.9, so it doesn't matter.

It looks like Tika already moved to JDK 1.7 [1] - so this should be ok for them.

So I'm "0" on this issue.

Andi.

[1] https://issues.apache.org/jira/browse/TIKA-1536
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Dominik Stadler
In reply to this post by Javen O'Neal
Hi,

I think we should switch to Java 7 post-3.14, I don't think any of those
things will reduce code size a lot, but most of these are quite useful as
soon as you get used to them.

Dominik.

On Wed, Dec 23, 2015 at 10:52 AM, Javen O'Neal <[hidden email]> wrote:

> Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
> released Java 7 in 2011 and ended support in 2015. Java 8 was released
> in 2014.
>
> There are a few language features introduced in Java 7 that would be
> nice to use in POI. This would mean asking everyone to move off of
> Java 6, but seems justifiable.
>
> I'd really like to use some of the Java 8 features, but usage of Java
> 7 is too prevalent today.
>
> A few Java 7 features that would be nice to use in the POI library:
> * switch statements on strings
> * improved generics type inference (diamond operator)
> * try-with-resources
> * try/multi-catch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Java 6 support

Uwe Schindler
Hi,

> I think we should switch to Java 7 post-3.14, I don't think any of those
> things will reduce code size a lot, but most of these are quite useful as
> soon as you get used to them.

Most of them can be applied automatically using Eclipse (e.g. diamonds). Multi-catch is very useful. Also think of refactoring reflection stuff with the new ReflectiveOperationException, common superclass of all reflection exceptions. Those changes reduce code size and improve readability.

Try-with-resources should be applied with great care for existing code. New code should always use it where possible (try-with resources won't work for classes that open a file in constructor and close them afterwards). I think there should be some code review that checks for leaks on resources, also making classes Closeable.

Uwe

>
> Dominik.
>
> On Wed, Dec 23, 2015 at 10:52 AM, Javen O'Neal <[hidden email]>
> wrote:
>
> > Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
> > released Java 7 in 2011 and ended support in 2015. Java 8 was released
> > in 2014.
> >
> > There are a few language features introduced in Java 7 that would be
> > nice to use in POI. This would mean asking everyone to move off of
> > Java 6, but seems justifiable.
> >
> > I'd really like to use some of the Java 8 features, but usage of Java
> > 7 is too prevalent today.
> >
> > A few Java 7 features that would be nice to use in the POI library:
> > * switch statements on strings
> > * improved generics type inference (diamond operator)
> > * try-with-resources
> > * try/multi-catch
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Nick Burch-2
In reply to this post by Javen O'Neal
On Wed, 23 Dec 2015, Javen O'Neal wrote:
> Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
> released Java 7 in 2011 and ended support in 2015. Java 8 was released
> in 2014.

Many of our users work for big conservative organisations, who'd much
rather throw money at a vendor to extend support rather than risk an
upgrade. As such, we've tended to be very slow to bump the minimum version
up, because of the potential impact, not only for our users directly, but
also those who get POI via frameworks/runtimes that also lag.

> There are a few language features introduced in Java 7 that would be
> nice to use in POI. This would mean asking everyone to move off of Java
> 6, but seems justifiable.

It might be best off asking on the user list how many people are still on
Java 6, to get an idea of how big an issue that would be. However, note
that many on the users list will be more advanced than the wider usage
base!

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

David kerber
I still use Java 6 with POI in production, and I would suggest that if
you bump up the required java level and start using the new language
features, then only do so when you bump the major version of POI.  To
me, bumping the required java is too big of a change for just a point
release of POI.



On 12/23/2015 9:43 AM, Nick Burch wrote:

> On Wed, 23 Dec 2015, Javen O'Neal wrote:
>> Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
>> released Java 7 in 2011 and ended support in 2015. Java 8 was released
>> in 2014.
>
> Many of our users work for big conservative organisations, who'd much
> rather throw money at a vendor to extend support rather than risk an
> upgrade. As such, we've tended to be very slow to bump the minimum
> version up, because of the potential impact, not only for our users
> directly, but also those who get POI via frameworks/runtimes that also lag.
>
>> There are a few language features introduced in Java 7 that would be
>> nice to use in POI. This would mean asking everyone to move off of
>> Java 6, but seems justifiable.
>
> It might be best off asking on the user list how many people are still
> on Java 6, to get an idea of how big an issue that would be. However,
> note that many on the users list will be more advanced than the wider
> usage base!
>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Javen O'Neal
According to [1], we ended support for JDK 1.5 in POI 3.11-beta 1. We added
commons-logging, commons-codec, and log4j in that version, so maybe those
libraries required Java 6+. None of our current dependencies require Java 7
yet.

> I'm ambivalent on this issue, as see our web sphere environment (at my
> $DAYJOB at a big insurance company) languish around on IBM JDK 1.5 / 1.6
...

I thought my ¢ompany was slow to upgrade. We switched off of Windows XP
weeks before Microsoft ended support, and switched to Java 7 only 18 months
ago. We finally upgraded to 64-bit Oracle JRE 7 so that people can run
applications using POI with more than 1024 MB max heap. This was a big deal
because 1GB heap can read up to 4MB Excel files using XSSF.

[1] http://poi.apache.org/changes.html
On Dec 23, 2015 7:43 AM, "David kerber" <[hidden email]> wrote:

> I still use Java 6 with POI in production, and I would suggest that if you
> bump up the required java level and start using the new language features,
> then only do so when you bump the major version of POI.  To me, bumping the
> required java is too big of a change for just a point release of POI.
>
>
>
> On 12/23/2015 9:43 AM, Nick Burch wrote:
>
>> On Wed, 23 Dec 2015, Javen O'Neal wrote:
>>
>>> Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
>>> released Java 7 in 2011 and ended support in 2015. Java 8 was released
>>> in 2014.
>>>
>>
>> Many of our users work for big conservative organisations, who'd much
>> rather throw money at a vendor to extend support rather than risk an
>> upgrade. As such, we've tended to be very slow to bump the minimum
>> version up, because of the potential impact, not only for our users
>> directly, but also those who get POI via frameworks/runtimes that also
>> lag.
>>
>> There are a few language features introduced in Java 7 that would be
>>> nice to use in POI. This would mean asking everyone to move off of
>>> Java 6, but seems justifiable.
>>>
>>
>> It might be best off asking on the user list how many people are still
>> on Java 6, to get an idea of how big an issue that would be. However,
>> note that many on the users list will be more advanced than the wider
>> usage base!
>>
>> Nick
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Bill Taylor
In reply to this post by Javen O'Neal
Thanks for keeping POI growing!  I'm a long-time user.  My day job finally
got to Java 6.  7 is a distant dream.  You could use yoda-time to get the
new date classes, at least.  That's what our developers do.

I filed a bug report [Bug 56454] XSSFSheet.shiftRows(...)
Is there any way to find out if someone is working on it or when I can get
a version with the fix?

Thanks.  Write on!

On Wed, Dec 23, 2015 at 4:52 AM, Javen O'Neal <[hidden email]> wrote:

> Oracle released Java 6 in 2006, ended support for Java 6 in 2013 and
> released Java 7 in 2011 and ended support in 2015. Java 8 was released
> in 2014.
>
> There are a few language features introduced in Java 7 that would be
> nice to use in POI. This would mean asking everyone to move off of
> Java 6, but seems justifiable.
>
> I'd really like to use some of the Java 8 features, but usage of Java
> 7 is too prevalent today.
>
> A few Java 7 features that would be nice to use in the POI library:
> * switch statements on strings
> * improved generics type inference (diamond operator)
> * try-with-resources
> * try/multi-catch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

kiwiwings
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Javen O'Neal-2
+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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Javen O'Neal-2
> (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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Dominik Stadler
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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Javen O'Neal-2
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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

kiwiwings
+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



signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Javen O'Neal-2
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" <[hidden email]> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

pj.fanning
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Dominik Stadler
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

kiwiwings
> 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


signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 6 support

Javen O'Neal-2
In reply to this post by pj.fanning
> 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" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Loading...