Hi,
PJ mentioned in the "Java 11“ thread that poi-ooxml-lite build times were slow,
so I eaned to look into this. I saw the following comment in
build.gradle.properties:
# Activating will be much faster, but break the build of 'poi-ooxml-lite‘
# @todo: look into poi-ooxml-lite task
@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.
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
+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
te 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:
>>
>> A
t;> 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 us
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
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
into contributing to commons-math so that we will see a JPMS compatible
release of that library too. If it gets done, POI will be finally be fully JPMS
compatible too.
Cheers,
Axel
> Am 06.01.2024 um 17:50 schrieb Axel Howind :
>
> Ah sorry, I wrote to the wrong list here. Was suppo
> On Saturday 6 January 2024 at 17:29:39 GMT+1, Axel Howind
> wrote:
>
>
>
>
>
> Happy New Year everybody!
>
> I want to ask about the roadmap to PDFBox 4.0, specifically:
>
> - Java version: currently PDFBox 4.0 is on Java 11. In the meantime,
Happy New Year everybody!
I want to ask about the roadmap to PDFBox 4.0, specifically:
- Java version: currently PDFBox 4.0 is on Java 11. In the meantime, we have
two newer LTS versions (17 and 21). Many important projects have decided to
bump minimum requirements to Java 17 in the meantime
ug.cgi?id=59393
>
> Axel Howind changed:
>
> What|Removed |Added
>
> Severity|normal |enhancement
>
> --
> You are receiving this
Hi Lynda,
thank you for offering to help. If you found an issue with Apache POI, you
should check the issue tracker first to see if this has already been reported.
If not, create an issue yourself.
Provide a reproducible example. The next step would be to check out the source
and build POI
+1 for the release.
I just built and tested one of my own projects with the RC and everything seems
to work just fine.
Two notes:
- I think release candidates should be published with an "rc“ in the version
string, something like "5.3.4-rc1“ because otherwise when a second release
hecked the mailing lists
> and there is no evidence that 2.19.0 has any security implications.
>
>
>
>
>
> On Tuesday 13 September 2022 at 11:02:24 IST, Axel Howind
> wrote:
>
>
>
>
>
> Hi,
>
> the colleagues over at log4j are preparing the 2.19.0 r
Hi,
the colleagues over at log4j are preparing the 2.19.0 release (currently in RC)
that adds a bugfix and support for SLF4J 2.0 that was requested by Spring devs.
They have found a last minute issue that is currently being worked on and will
probably release soon. Maybe it's worth to wait for
[
https://issues.apache.org/jira/browse/XMLBEANS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534890#comment-17534890
]
Axel Howind commented on XMLBEANS-606:
--
Ah, my bad. I thought it was derived from Throwable
[
https://issues.apache.org/jira/browse/XMLBEANS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534839#comment-17534839
]
Axel Howind commented on XMLBEANS-606:
--
Can you provide an example of a badly formatted error
+1
> Am 07.01.2022 um 09:44 schrieb PJ Fanning :
>
> Hi everyone,
>
> I've prepared artifacts for the release of Apache POI 5.2.0 (RC2).
>
>
> The most notable changes in this release are:
>
> * upgrade dependencies: XmlBeans 5.0.3, XMLSec 2.3.0, BouncyCastle 1.70,
> Log4j-API 2.17.1,
+1
Von meinem iPhone gesendet
> Am 12.12.2021 um 20:52 schrieb Andreas Beeker :
>
> Hi PJ,
>
>> On 12.12.21 11:07, PJ Fanning wrote:
>> If there are no objections, I propose to create a RC1 for XMLBeans 5.0.3
>> today.
>>
> +1.
>
> Do you prepare it or should I do it?
>
> Andi
>
>
>
Sorry, I have been out of the loop for some time. I just discovered that I can
use the staging artefacts directly by adding the staging repository to my build
files, this makes things much easier. Looks good in my projects.
+1
AFAIK slf4j 1.7 doesn’t support JPMS. I also think slf4j is more or less dead
and would welcome to move on to log4j2.
Von meinem iPhone gesendet
> Am 23.09.2021 um 21:25 schrieb Alain FAGOT BÉAREZ :
>
> Hi,
>
> The company where I work currently also uses 1.7.32 with no reason to use any
>
Hi Andi,
two more things to consider:
- Jigsaw support. The module system has been around for some years now, and
libraries still have to fully support it. From what I read, Log4J2 seems to
support Jigsaw, whereas SLF4J/Logback still only has it in Beta-versions.
- Active development. The
Hi Andy,
That’s great news!
I think changing the module names makes this is breaking change, so will the
release containing these changes be version 5.0 or a 4.x? I think I would go
for 5.0 on the assumption that module and package names will stay stable for
the foreseeable future.
But I
+1
> On 3. Feb 2020, at 22:14, Andreas Beeker wrote:
>
> Hi *,
>
> I've prepared artifacts for the release of Apache POI 4.1.2 (RC2).
>
> The most notable changes in this release are:
>
> - XDDF - some work on better chart support
> - Common SL / EMF - ongoing rendering fixes - see #60656
>
>
> On 2019/10/08 13:07:37, Axel Howind wrote:
> > Hi,
> >
> > you have to use
> > [Cell.getRichStringCellValue()](https://poi.apache.org/apidocs/dev/org/apache/poi/ss/usermodel/Cell.html#getRichStringCellValue--).
> > But I think questions
GenericRecordJsonWriter is not
> conformant :(,
> but this is a new feature, so I'll fix it for POI 4.1.2
>
>
>
> On 18.10.19 23:27, Axel Howind wrote:
> > Hi,
> >
> > as it seems my changes for "Add support for new java.time API" are in trunk
> > now,
Hi,
as it seems my changes for "Add support for new java.time API" are in trunk
now, will they be part of 4.1.1? At least for my own projects it's a notable
change, since I will be able to throw out lots of conversion code from my own
projects once it's released. ;-)
Axel
On 2019/10/16
Hi,
you have to use
[Cell.getRichStringCellValue()](https://poi.apache.org/apidocs/dev/org/apache/poi/ss/usermodel/Cell.html#getRichStringCellValue--).
But I think questions like this rather belong in the [POI user
list](https://lists.apache.org/list.html?u...@poi.apache.org).
Axel
On
Can you provide the complete error message you get? The file name looks
suspicious to me. It should start with an Uppercase letter.
On 2019/10/07 02:22:02, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63810
>
> --- Comment #2 from gundae ---
> This problem
in the code base where that could be used to make POI
a little more lightweight.
Please review and comment.
Axel
On 2019/09/28 08:59:56, Axel Howind wrote:
> Ok, I'll create an RFE and add a pull request.
>
> On 2019/09/27 15:57:08, Nick Burch wrote:
> > On Fri, 27 Sep 2019, Ax
Ok, I'll create an RFE and add a pull request.
On 2019/09/27 15:57:08, Nick Burch wrote:
> On Fri, 27 Sep 2019, Axel Howind wrote:
> > since version 4.0.1, POI requires at least Java 8. I suggest adding
> > support for the new Java Date/Time API introduced with that version
Hi,
since version 4.0.1, POI requires at least Java 8. I suggest adding support for
the new Java Date/Time API introduced with that version of the JDK, i.e.
`Cell.getLocalDateValue()` `Cell.getLocalDateTimeValue()` and two matching
overloads of `Cell.setCellValue()`. What do you think? If I
Hello Kirill,
Nor am I a regular reader of this list, neither I am a regular POI committer -
but from time to time, I fix bugs that I encounter. Nevertheless, I think I can
share some advice on how to get help with your issue:
1. Put some effort in it before asking on the list: if you think
Hi,
SXSSF can definitely work with large Excel sheets. But SXSSF is for writing.
Your problem is with XSSF because you have to read in the large file first.
SXSSF is really very helpful and usable, and I don’t know what most developers
need, but I mostly need it for writing new large excel
When looking at the current source, I noticed Hashtable still being used
in a number of places. Is there any reason for not replacing all these
hashtable instances with HashMap (besides TestContentType.java failing,
see below)?
I attach a patch that replaces Hashtable instantiations with
Created Bug 59743 and attached patch.
> > Once there is consensus on how POI should handle this, open a new bug that
> > "depends on" bug 58499.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional
The main purpose of the zip bomb detection is to safely handle untrusted input.
Since a workbook that has already been fully read into memory has passed the
safety test, I suppose you could consider it quasi-safe with regard to writing
it back out.
If you can't think of a way that a latent zip
38 matches
Mail list logo
