commons-io
commons-io copied to clipboard
Replace a number of deprecated methods
Most;y by adding explicit charsets, except in the cases where the omission of a charset was what was being tested
Codecov Report
Merging #495 (ee5c9db) into master (43594ce) will decrease coverage by
0.05%. Report is 2 commits behind head on master. The diff coverage isn/a.
@@ Coverage Diff @@
## master #495 +/- ##
============================================
- Coverage 84.97% 84.92% -0.05%
+ Complexity 3372 3370 -2
============================================
Files 227 227
Lines 8080 8080
Branches 953 953
============================================
- Hits 6866 6862 -4
- Misses 960 964 +4
Partials 254 254
see 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
-1: We have to test ALL the code we provide. Also, notice this PR decreases the code coverage percentage:
@@ Coverage Diff @@
## master #495 +/- ##
============================================
- Coverage 84.97% 84.92% -0.05%
+ Complexity 3372 3370 -2
============================================
Files 227 227
Lines 8080 8080
Branches 953 953
============================================
- Hits 6866 6862 -4
- Misses 960 964 +4
Partials 254 254
I think in all cases here each method still tests what it tested before. Only setup and verification code has been rewritten to use non-deprecated methods and to be more platform independent. There were a couple places I left unchanged precisely because they test deprecated method. If I missed one of those, point to it and I'll fix it.
Code coverage numbers are not accurate to three significant figures.
We need to keep the code as is to show it works on Java 18 and up where the default encoding is UTF-8. We should consider undeprecating these methods on Java 18 and up.
That would be nice. Unfortunately, "An implementation may override the default charset with the system property file.encoding on the command line. If the value is COMPAT, the default charset is derived from the native.encoding system property, which typically depends upon the locale and charset of the underlying operating system." so we're going to need to specify charsets for the next 25 years. :-(
We might end up setting up separate JDK 21 CIs, one with UTF-8 and one with something weird like Cp936, to flush out the issues.
We might end up setting up separate JDK 21 CIs, one with UTF-8 and one with something weird like Cp936, to flush out the issues.
That sounds good (and interesting) but this PR should be closed.
I need to take another look at this, but I'm not convinced the existing tests are correct or testing what they think they're testing.
Closing: See above.