On Thu, 21 Jul 2022 19:42:05 GMT, Alexander Zvegintsev <[email protected]> wrote:
> After applying the fix, I see that the tracker window closes when it reaches > the limit, while the progress may be still ongoing for a prolonged period > time. It doesn't look right to me. > > I think we can either change this close condition, either fake progress to > MAX_INT-1 until we actually reach the end. > > Anyway it seems like a workaround, real solution would be to migrate to > long(probably by adding new constructors and methods to keep compatibility). Yes, the tracker closes when it reaches MAX INT limit 2147483647 since the progress tracking method setProgress() accepts "int". We can keep the progress meter at end ie 100% without closing even after reading 2147483647 bytes, till it reaches EOF or we could add new setProgress() method with long as you suggested. I had thought about it but was not sure about the practicality of this scenario, so just thought of addressing by closing the tracker. Also, InputStream.available() returns an "int" so I guessed filesize > MAX_INT is not supported which is another reason I did not go for "long" I will update the fix for the former. > It doesn't have to be a FileInputStream, since ProgressMonitorInputStream > accepts InputStream. So we can make a dummy one with no real data backing it. I tried creating ByteArrayInputStream of 3GB but it fails with NegativeArraySizeException because of overflow so I am not sure if it's possible. ------------- PR: https://git.openjdk.org/jdk/pull/9588
