Itext Java 11: Illegal reflective access by com.itextpdf.io.source.ByteBufferRandomAccessSource$1










3















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











share|improve this question
























  • 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















3















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











share|improve this question
























  • 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













3












3








3


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











share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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

















  • 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












2 Answers
2






active

oldest

votes


















1














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.






share|improve this answer























  • Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.

    – D. Millard
    Nov 15 '18 at 10:19


















0














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.






share|improve this answer























  • 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










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
);



);













draft saved

draft discarded


















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









1














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.






share|improve this answer























  • Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.

    – D. Millard
    Nov 15 '18 at 10:19















1














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.






share|improve this answer























  • Wrapping the PdfWriter and PdfReader Strings in new FileOutputStreams FileInputStreams did fix it.

    – D. Millard
    Nov 15 '18 at 10:19













1












1








1







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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

















  • 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













0














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.






share|improve this answer























  • 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















0














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.






share|improve this answer























  • 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













0












0








0







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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

















  • 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

















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







這個網誌中的熱門文章

Barbados

How to read a connectionString WITH PROVIDER in .NET Core?

Node.js Script on GitHub Pages or Amazon S3