> 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 cod
> 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
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
nec
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 bac
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 iss
+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'r
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/writ
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
> (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
inte
+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
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
--
Vi
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
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 (
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 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
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 thi
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 wrote:
> Oracle released Java 6 in 2006, ended support fo
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
18 matches
Mail list logo
