valerybokov commented on PR #383: URL: https://github.com/apache/pdfbox/pull/383#issuecomment-3691430860
> How could you be so sure that you checked all cases? I had a quick look and there are different branches which get confusing there one dig deeper into it. Many of them ended in java.net.URLConnection.getInputStream() which is implemented by several classes and some are JDK specific, so that there might be other implementations in other JDK you never saw. I've found one example in the corretto JDK which uses an ByteArrayInput stream: sun.net.www.protocol.file.FileURLConnection.getInputStream() > > I'm afraid the assumption that all implementations are already returning a buffered stream is not correct. > > I agree with @THausherr and won't support a check. Did you have some cases where such a change introduces a real improvement? Can I be responsible for all cases in the JDK? I only tested this on the trunk branch. I mean, I tested all the cases I'm requesting to change. I understand this is a weak argument, but PDFBox tests run noticeably faster after my changes. As I said earlier, you're wrapping a buffered stream inside a buffered stream. The methods of these classes are synchronized. Obviously, execution will be slower due to double synchronization. My suggestion applies only to library resources. These are relatively small files. You don't want to add a check. Even if the getResourceAsStream method returns an unbuffered stream (I think it will always be buffered for new JDK versions), you don't lose anything significant. In my opinion, having a check will be a safer and faster option than your double synchronization. Although, I repeat, I am not insisting on type checking, I am only saying (as does chat gpt) that there is no guarantee that a buffered stream will always be returned. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
