[
https://issues.apache.org/jira/browse/PDFBOX-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836295#comment-16836295
]
Tilman Hausherr commented on PDFBOX-4538:
-----------------------------------------
There is a text somewhere that explains why we don't expose much, I can't find
it, but "Effective Java" has a similar explanation. Exposing everything means
that internals can't be changed easily without changing the version, and also
people come up with weird manipulations that were not thought about in the
first place.
> Expose more internal API as protected and public
> ------------------------------------------------
>
> Key: PDFBOX-4538
> URL: https://issues.apache.org/jira/browse/PDFBOX-4538
> Project: PDFBox
> Issue Type: Improvement
> Components: Parsing, Rendering, Writing
> Affects Versions: 2.0.14
> Reporter: Jonathan
> Priority: Minor
> Labels: pull-request-available
> Fix For: 2.0.16
>
>
> During the last couple of weeks, I worked intensely on PDFBox-based, heavy
> PDF processing.
> In the course of this work, we often needed to customize some behaviour of
> the library, but we haven't been able to do this as an extension by
> subclassing. Instead, we needed to fork the entire project, with the majority
> of changes being the use of less restrictive access modifiers.
> As a company we would like to reduce the scope of our own modifications, so
> it'd be great if you could adopt a somewhat less restrictive policy on
> exposing API area. I could compile a list of the symbols we needed, but
> perhaps it would make sense to undergo a more general review about what
> internals could be opened as public API.
> We also implemented some other fixes, I will open separate issues to address
> them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
