FileOutput should write to FileOutputStream via BufferedOutputStream#2073
Merged
Conversation
5c23076 to
22625e7
Compare
22625e7 to
723e54c
Compare
Member
Author
@marchof while this was 13 years ago, do you by chance remember 😅 or see any reasons why the use of BufferedOutputStream was removed, or was it simply overlooked? 😉 Also for the changelog entry I'm divided about how to classify this - as enhancement or bug-fix for regression? 😆 |
Member
|
@Godin Sure I clearly remember. I did this on purpose to see how long it takes you to find out about it. 🤣 Just joking: Many thanks for catching any analyzing this is detail! |
marchof
approved these changes
Mar 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While working on #2065 I noticed that
org.jacoco.agent.rt.internal.output.FileOutputdoes not write toFileOutputStreamviaBufferedOutputStream.What seems to be regression after 4906467 of #61 in version
0.6.2There is also inconsistency with
org.jacoco.core.tools.ExecFileLoaderwhich does.Following test
demonstrates that one of the two JaCoCo runtimes writing to the same file within one JVM won't be able to wait for file lock release within allowed 3 seconds while other writes 4 MiB of execution data (33 554 432 probes)
And while such situation seems unlikely - size of complete execution data for all classes in
org.jacoco.report/target/classesis about 3.8K (1 260 probes),org.jacoco.report.testproduces about 9.8Korg.jacoco.core/target/classesis about 13K (3 773 probes),org.jacoco.core.testproduces about 25Kjacoco-0.8.14.zipis about 98K (49 684 probes)java.base.jmodof JDK 25 is about 394K (300 133 probes)kotlin-compiler-2.3.0.zipis about 2.9M (1 335 895 probes)wildfly-39.0.1.Final.zipis about 9M (4 469 140 probes)IMO this is anyway good improvement.
For the record here is results of execution on my machine of benchmark added in this PR for
org.jacoco.core.internal.data.CompactDataOutput: