Itext Java 11: Illegal reflective access by com.itextpdf.io.source.ByteBufferRandomAccessSource$1
Recently upgraded to Java 11 and began performing a regression check. Currently get an Illegal reflective access error when trying to call com.itextpdf.text.pdf.PdfReader.close
. Currently on Itext version 5.5.13 but also tried on itext 7.0.0 and had same issue.
Does anyone have any suggestions on how to fix compatibility issues between Java-11 and Itext?
WARNING: An illegal reflective access operation has occurred WARNING:
Illegal reflective access by
com.itextpdf.io.source.ByteBufferRandomAccessSource$1
(file:...repository/com/itextpdf/io/7.0.0/io-7.0.0.jar) to method
java.nio.DirectByteBuffer.cleaner() WARNING: Please consider reporting
this to the maintainers of
com.itextpdf.io.source.ByteBufferRandomAccessSource$1 WARNING: Use
--illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be
denied in a future release
java itext itext7 java-11
add a comment |
Recently upgraded to Java 11 and began performing a regression check. Currently get an Illegal reflective access error when trying to call com.itextpdf.text.pdf.PdfReader.close
. Currently on Itext version 5.5.13 but also tried on itext 7.0.0 and had same issue.
Does anyone have any suggestions on how to fix compatibility issues between Java-11 and Itext?
WARNING: An illegal reflective access operation has occurred WARNING:
Illegal reflective access by
com.itextpdf.io.source.ByteBufferRandomAccessSource$1
(file:...repository/com/itextpdf/io/7.0.0/io-7.0.0.jar) to method
java.nio.DirectByteBuffer.cleaner() WARNING: Please consider reporting
this to the maintainers of
com.itextpdf.io.source.ByteBufferRandomAccessSource$1 WARNING: Use
--illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be
denied in a future release
java itext itext7 java-11
Have you tried it on the latest iText version (which is 7.1.4 as of today)?. I believe similar issue was encountered for the Java 9, and I think it was fixed.
– Yulian Gaponenko
Nov 14 '18 at 13:47
And if you find a solution, can you submit a pull request for iText 7? That would be great! We won't update it for iText 5 though because it is end-of-life.
– Amedee Van Gasse
Nov 14 '18 at 13:48
Also, can you reproduce with 7.1.4?
– Amedee Van Gasse
Nov 14 '18 at 13:49
Yes, I've been having same issue with 7.1.4 too
– D. Millard
Nov 14 '18 at 14:16
add a comment |
Recently upgraded to Java 11 and began performing a regression check. Currently get an Illegal reflective access error when trying to call com.itextpdf.text.pdf.PdfReader.close
. Currently on Itext version 5.5.13 but also tried on itext 7.0.0 and had same issue.
Does anyone have any suggestions on how to fix compatibility issues between Java-11 and Itext?
WARNING: An illegal reflective access operation has occurred WARNING:
Illegal reflective access by
com.itextpdf.io.source.ByteBufferRandomAccessSource$1
(file:...repository/com/itextpdf/io/7.0.0/io-7.0.0.jar) to method
java.nio.DirectByteBuffer.cleaner() WARNING: Please consider reporting
this to the maintainers of
com.itextpdf.io.source.ByteBufferRandomAccessSource$1 WARNING: Use
--illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be
denied in a future release
java itext itext7 java-11
Recently upgraded to Java 11 and began performing a regression check. Currently get an Illegal reflective access error when trying to call com.itextpdf.text.pdf.PdfReader.close
. Currently on Itext version 5.5.13 but also tried on itext 7.0.0 and had same issue.
Does anyone have any suggestions on how to fix compatibility issues between Java-11 and Itext?
WARNING: An illegal reflective access operation has occurred WARNING:
Illegal reflective access by
com.itextpdf.io.source.ByteBufferRandomAccessSource$1
(file:...repository/com/itextpdf/io/7.0.0/io-7.0.0.jar) to method
java.nio.DirectByteBuffer.cleaner() WARNING: Please consider reporting
this to the maintainers of
com.itextpdf.io.source.ByteBufferRandomAccessSource$1 WARNING: Use
--illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be
denied in a future release
java itext itext7 java-11
java itext itext7 java-11
edited Nov 14 '18 at 13:59
Mikhail Kholodkov
4,60252747
4,60252747
asked Nov 14 '18 at 13:17
D. MillardD. Millard
184
184
Have you tried it on the latest iText version (which is 7.1.4 as of today)?. I believe similar issue was encountered for the Java 9, and I think it was fixed.
– Yulian Gaponenko
Nov 14 '18 at 13:47
And if you find a solution, can you submit a pull request for iText 7? That would be great! We won't update it for iText 5 though because it is end-of-life.
– Amedee Van Gasse
Nov 14 '18 at 13:48
Also, can you reproduce with 7.1.4?
– Amedee Van Gasse
Nov 14 '18 at 13:49
Yes, I've been having same issue with 7.1.4 too
– D. Millard
Nov 14 '18 at 14:16
add a comment |
Have you tried it on the latest iText version (which is 7.1.4 as of today)?. I believe similar issue was encountered for the Java 9, and I think it was fixed.
– Yulian Gaponenko
Nov 14 '18 at 13:47
And if you find a solution, can you submit a pull request for iText 7? That would be great! We won't update it for iText 5 though because it is end-of-life.
– Amedee Van Gasse
Nov 14 '18 at 13:48
Also, can you reproduce with 7.1.4?
– Amedee Van Gasse
Nov 14 '18 at 13:49
Yes, I've been having same issue with 7.1.4 too
– D. Millard
Nov 14 '18 at 14:16
Have you tried it on the latest iText version (which is 7.1.4 as of today)?. I believe similar issue was encountered for the Java 9, and I think it was fixed.
– Yulian Gaponenko
Nov 14 '18 at 13:47
Have you tried it on the latest iText version (which is 7.1.4 as of today)?. I believe similar issue was encountered for the Java 9, and I think it was fixed.
– Yulian Gaponenko
Nov 14 '18 at 13:47
And if you find a solution, can you submit a pull request for iText 7? That would be great! We won't update it for iText 5 though because it is end-of-life.
– Amedee Van Gasse
Nov 14 '18 at 13:48
And if you find a solution, can you submit a pull request for iText 7? That would be great! We won't update it for iText 5 though because it is end-of-life.
– Amedee Van Gasse
Nov 14 '18 at 13:48
Also, can you reproduce with 7.1.4?
– Amedee Van Gasse
Nov 14 '18 at 13:49
Also, can you reproduce with 7.1.4?
– Amedee Van Gasse
Nov 14 '18 at 13:49
Yes, I've been having same issue with 7.1.4 too
– D. Millard
Nov 14 '18 at 14:16
Yes, I've been having same issue with 7.1.4 too
– D. Millard
Nov 14 '18 at 14:16
add a comment |
2 Answers
2
active
oldest
votes
While I second the comments encouraging you to debug the code and find the root cause (and then submit a pull request), or creating an issue in iText Jira if you are a customer with a support contract (which would raise the priority of the issue), here is a workaround suggestion (that I haven't tested, but I chances are it will work):
Use PdfReader
and PdfWriter
constructors that accept InputStream
and OutputStream
, respectively. In this case the code causing the problem should not be invoked. Same thing for all the other cases in which iText interacts with your file system - wrap everything into InputStream
/OutputStream
, or deal with byte
arrays.
So this line:
new PdfDocument(new PdfReader(inFilePath), new PdfWriter(outFilePath))
becomes this one:
new PdfDocument(new PdfReader(new FileInputStream(inFilePath)),
new PdfWriter(new FileOutputStream(outFilePath)))
You might also want to wrap the streams into BufferedInputStream
/BufferedOutputStream
.
Similarly, when dealing with PdfFontFactory
, use methods that accept byte
instead of String
representing file path and so on.
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
add a comment |
If you're curious what is the Illegal Reflective Access is all about, please refer here: what is an illegal reflective access
This particular warning comes from this class:
https://github.com/itext/itext7/blob/develop/io/src/main/java/com/itextpdf/io/source/ByteBufferRandomAccessSource.java
From this particular method:
private static boolean clean(final java.nio.ByteBuffer buffer)
if (buffer == null
This line exactly:
getCleanerMethod.setAccessible(true);
As long as this warning does not prevent iText from working as expected, I think the best you can do is to submit an issue/PR to iText team and wait for the proper fix to be available.
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Shouldn't the code go through the "// java 9
" branch rather than the "// java 8 and lower
"?
– Holger
Nov 15 '18 at 22:50
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53301158%2fitext-java-11-illegal-reflective-access-by-com-itextpdf-io-source-bytebufferran%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
While I second the comments encouraging you to debug the code and find the root cause (and then submit a pull request), or creating an issue in iText Jira if you are a customer with a support contract (which would raise the priority of the issue), here is a workaround suggestion (that I haven't tested, but I chances are it will work):
Use PdfReader
and PdfWriter
constructors that accept InputStream
and OutputStream
, respectively. In this case the code causing the problem should not be invoked. Same thing for all the other cases in which iText interacts with your file system - wrap everything into InputStream
/OutputStream
, or deal with byte
arrays.
So this line:
new PdfDocument(new PdfReader(inFilePath), new PdfWriter(outFilePath))
becomes this one:
new PdfDocument(new PdfReader(new FileInputStream(inFilePath)),
new PdfWriter(new FileOutputStream(outFilePath)))
You might also want to wrap the streams into BufferedInputStream
/BufferedOutputStream
.
Similarly, when dealing with PdfFontFactory
, use methods that accept byte
instead of String
representing file path and so on.
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
add a comment |
While I second the comments encouraging you to debug the code and find the root cause (and then submit a pull request), or creating an issue in iText Jira if you are a customer with a support contract (which would raise the priority of the issue), here is a workaround suggestion (that I haven't tested, but I chances are it will work):
Use PdfReader
and PdfWriter
constructors that accept InputStream
and OutputStream
, respectively. In this case the code causing the problem should not be invoked. Same thing for all the other cases in which iText interacts with your file system - wrap everything into InputStream
/OutputStream
, or deal with byte
arrays.
So this line:
new PdfDocument(new PdfReader(inFilePath), new PdfWriter(outFilePath))
becomes this one:
new PdfDocument(new PdfReader(new FileInputStream(inFilePath)),
new PdfWriter(new FileOutputStream(outFilePath)))
You might also want to wrap the streams into BufferedInputStream
/BufferedOutputStream
.
Similarly, when dealing with PdfFontFactory
, use methods that accept byte
instead of String
representing file path and so on.
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
add a comment |
While I second the comments encouraging you to debug the code and find the root cause (and then submit a pull request), or creating an issue in iText Jira if you are a customer with a support contract (which would raise the priority of the issue), here is a workaround suggestion (that I haven't tested, but I chances are it will work):
Use PdfReader
and PdfWriter
constructors that accept InputStream
and OutputStream
, respectively. In this case the code causing the problem should not be invoked. Same thing for all the other cases in which iText interacts with your file system - wrap everything into InputStream
/OutputStream
, or deal with byte
arrays.
So this line:
new PdfDocument(new PdfReader(inFilePath), new PdfWriter(outFilePath))
becomes this one:
new PdfDocument(new PdfReader(new FileInputStream(inFilePath)),
new PdfWriter(new FileOutputStream(outFilePath)))
You might also want to wrap the streams into BufferedInputStream
/BufferedOutputStream
.
Similarly, when dealing with PdfFontFactory
, use methods that accept byte
instead of String
representing file path and so on.
While I second the comments encouraging you to debug the code and find the root cause (and then submit a pull request), or creating an issue in iText Jira if you are a customer with a support contract (which would raise the priority of the issue), here is a workaround suggestion (that I haven't tested, but I chances are it will work):
Use PdfReader
and PdfWriter
constructors that accept InputStream
and OutputStream
, respectively. In this case the code causing the problem should not be invoked. Same thing for all the other cases in which iText interacts with your file system - wrap everything into InputStream
/OutputStream
, or deal with byte
arrays.
So this line:
new PdfDocument(new PdfReader(inFilePath), new PdfWriter(outFilePath))
becomes this one:
new PdfDocument(new PdfReader(new FileInputStream(inFilePath)),
new PdfWriter(new FileOutputStream(outFilePath)))
You might also want to wrap the streams into BufferedInputStream
/BufferedOutputStream
.
Similarly, when dealing with PdfFontFactory
, use methods that accept byte
instead of String
representing file path and so on.
answered Nov 14 '18 at 19:16
Alexey SubachAlexey Subach
4,80972143
4,80972143
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
add a comment |
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.
– D. Millard
Nov 15 '18 at 10:19
add a comment |
If you're curious what is the Illegal Reflective Access is all about, please refer here: what is an illegal reflective access
This particular warning comes from this class:
https://github.com/itext/itext7/blob/develop/io/src/main/java/com/itextpdf/io/source/ByteBufferRandomAccessSource.java
From this particular method:
private static boolean clean(final java.nio.ByteBuffer buffer)
if (buffer == null
This line exactly:
getCleanerMethod.setAccessible(true);
As long as this warning does not prevent iText from working as expected, I think the best you can do is to submit an issue/PR to iText team and wait for the proper fix to be available.
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Shouldn't the code go through the "// java 9
" branch rather than the "// java 8 and lower
"?
– Holger
Nov 15 '18 at 22:50
add a comment |
If you're curious what is the Illegal Reflective Access is all about, please refer here: what is an illegal reflective access
This particular warning comes from this class:
https://github.com/itext/itext7/blob/develop/io/src/main/java/com/itextpdf/io/source/ByteBufferRandomAccessSource.java
From this particular method:
private static boolean clean(final java.nio.ByteBuffer buffer)
if (buffer == null
This line exactly:
getCleanerMethod.setAccessible(true);
As long as this warning does not prevent iText from working as expected, I think the best you can do is to submit an issue/PR to iText team and wait for the proper fix to be available.
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Shouldn't the code go through the "// java 9
" branch rather than the "// java 8 and lower
"?
– Holger
Nov 15 '18 at 22:50
add a comment |
If you're curious what is the Illegal Reflective Access is all about, please refer here: what is an illegal reflective access
This particular warning comes from this class:
https://github.com/itext/itext7/blob/develop/io/src/main/java/com/itextpdf/io/source/ByteBufferRandomAccessSource.java
From this particular method:
private static boolean clean(final java.nio.ByteBuffer buffer)
if (buffer == null
This line exactly:
getCleanerMethod.setAccessible(true);
As long as this warning does not prevent iText from working as expected, I think the best you can do is to submit an issue/PR to iText team and wait for the proper fix to be available.
If you're curious what is the Illegal Reflective Access is all about, please refer here: what is an illegal reflective access
This particular warning comes from this class:
https://github.com/itext/itext7/blob/develop/io/src/main/java/com/itextpdf/io/source/ByteBufferRandomAccessSource.java
From this particular method:
private static boolean clean(final java.nio.ByteBuffer buffer)
if (buffer == null
This line exactly:
getCleanerMethod.setAccessible(true);
As long as this warning does not prevent iText from working as expected, I think the best you can do is to submit an issue/PR to iText team and wait for the proper fix to be available.
answered Nov 14 '18 at 13:58
Mikhail KholodkovMikhail Kholodkov
4,60252747
4,60252747
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Shouldn't the code go through the "// java 9
" branch rather than the "// java 8 and lower
"?
– Holger
Nov 15 '18 at 22:50
add a comment |
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Shouldn't the code go through the "// java 9
" branch rather than the "// java 8 and lower
"?
– Holger
Nov 15 '18 at 22:50
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Unfortunately the PdfDocument object appears to not close the document. As also seen during debugging as couldn't manually delete the file also due to itext still having hold of the pdf.
– D. Millard
Nov 14 '18 at 14:19
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Then it's a major bug. You probably want to debug the iText flow itself to find out the root cause. Simple warning should not break such things as resource closing.
– Mikhail Kholodkov
Nov 14 '18 at 15:09
Shouldn't the code go through the "
// java 9
" branch rather than the "// java 8 and lower
"?– Holger
Nov 15 '18 at 22:50
Shouldn't the code go through the "
// java 9
" branch rather than the "// java 8 and lower
"?– Holger
Nov 15 '18 at 22:50
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53301158%2fitext-java-11-illegal-reflective-access-by-com-itextpdf-io-source-bytebufferran%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Have you tried it on the latest iText version (which is 7.1.4 as of today)?. I believe similar issue was encountered for the Java 9, and I think it was fixed.
– Yulian Gaponenko
Nov 14 '18 at 13:47
And if you find a solution, can you submit a pull request for iText 7? That would be great! We won't update it for iText 5 though because it is end-of-life.
– Amedee Van Gasse
Nov 14 '18 at 13:48
Also, can you reproduce with 7.1.4?
– Amedee Van Gasse
Nov 14 '18 at 13:49
Yes, I've been having same issue with 7.1.4 too
– D. Millard
Nov 14 '18 at 14:16