[
https://issues.apache.org/jira/browse/PDFBOX-4548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840232#comment-16840232
]
Sergey Beryozkin commented on PDFBOX-4548:
------------------------------------------
Thanks for the initial feedback.
Right, it would require changes and this is why I'm only hoping for them to
make it to a new major release.
IMHO it would not be a bad idea to introduce an indirect access to those
well-known PDType1Font instances in general anyway, for the users work with
them via the enum bridge, as opposed to having to access the static instances
directly, and the enum can be enhanced in the future with some other useful
methods (note in the current PDType1Font source there is a note to consider
moving them to either enum or getters so I'm assuming it was considered at a
time). So may be it can be considered as a general improvement. I guess if it
won't make to 3.0.0 then it would have no chance at all, so may be it is either
now or never or much much later :-)
GraalVM is a new thing for me as well (I'm learning myself, it is JVM with
extra features, ahead of time compilation, creation of native images, etc).
I've started working on a [Tika
extension|https://github.com/sberyozkin/quarkus/tree/tika_extension/extensions/tika]
for [Quarkus|https://github.com/quarkusio/quarkus] which can help with
creating native images for GraalVM among other things and this is how I came
across the issue. It all works fine in a 'plain' HotSpot Java mode but fails
when the attempt is made to compile to a native image.
I have a workaround, I'd like to ask my colleagues about it and will get back
on it, but as far as the native compilation is concerned, I thought [this blog
entry|https://developers.redhat.com/blog/2019/03/29/quarkus-why-compile-to-native/]
was informative.
If it can be of interest I can describe a sequence which can be used to run
[this demo|http://example.com] in both 'plain' and 'native' mode. In the latter
case it is all very instant, it is a pure C code as far as I understand. And
this sequence could confirm the effectiveness of this fix.
So I reckon it would affect PDFBox positively going forward for it be native
mode ready, as more users may want to try it in the native mode over time. I
appreciate there would be a migration cost for 3.0.0 but it should be worth it
> Update PDType1Font to make PDFBox GraalVM native mode ready
> ------------------------------------------------------------
>
> Key: PDFBOX-4548
> URL: https://issues.apache.org/jira/browse/PDFBOX-4548
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
> Affects Versions: 2.0.16
> Reporter: Sergey Beryozkin
> Priority: Major
> Fix For: 3.0.0 PDFBox
>
>
> {{org.apache.pdfbox.pdmodel.font.PDType1Font}} has statically initialized
> PDType1Font instances with the private constructor having a code path to
> {{org.apache.fontbox.ttf.RAFDataStream}} which opens a File.
> This prevents [GraalVM|https://github.com/oracle/graal] from building a
> native image of PDFBox or libraries which depend on it.
> Please see [TIKA-2862|https://issues.apache.org/jira/browse/TIKA-2862] for
> more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
