Re: [CANCEL][VOTE] Release Apache Commons IO 2.12.0 based on RC1
Cool sounds good. -Rob > On May 3, 2023, at 9:55 AM, Gary Gregory wrote: > > Thanks Rob! Make sure you track git master as I am going through Alex's > comments and pushing updates, I should be done tonight. > > Gary > > On Wed, May 3, 2023, 08:22 Rob Tompkins wrote: > >> I was reading this release over yesterday. I’m still looking at the code >> changes generally. >> >> Cheers, >> -Rob >> >>> On May 2, 2023, at 7:31 PM, Gary Gregory wrote: >>> >>> Great review Alex, TY, I am canceling this vote and will reply to this >>> email with details. >>> >>> Gary >>> >>> On Tue, May 2, 2023, 12:14 Alex Herbert >> wrote: >>> Validated signatures and checksums. Build from source tar.gz file using 'mvn verify site' with: Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584) Maven home: /usr/local/apache-maven-3 Java version: 11.0.18, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-148-generic", arch: "amd64", family: "unix" I do see the checkstyle and spotbugs report. Spotbugs has a few mentions of non-serializable fields. This is another case where we may not wish to support serialization going forward (e.g. as with CSV). I cannot remember the solution for CSV. I think it was a formal documentation that serialization will be dropped in CSV 2.0. Looking at the error these are not new as the report in the live site for 2.11.0 also has these. Checked for the @since tag for new items in the japicmp report and found no missing tags. I note that some of the new classes in package io.build have no javadoc on inner classes with public constructors and some static helper protected methods. New helper classes with a private constructor should be final: CharsetDecoders CharsetEncoders FilesUncheck FileTimes Changing public classes to final after a release breaks binary compatibility. However other utility classes in the lib do not use final for classes so this is not critical. FYI there are 5 others which I found using PMD. The rule is ClassWithOnlyPrivateConstructorsShouldBeFinal [1]. This is not part of the default rules used in the project which is using the default from the maven plugin [2]. If you run 'mvn pmd:check' the rules are written to target/pmd/rulesets. I took these rules, added the extra rule and then used this as the ruleset for PMD. The new IOBiFunction has a noop method. This has no equivalent in java.util.function.BiFunction. As discussed on a recent PR for Lang (adding a noop to TriFunction) it does not make sense to have a noop function that returns null as this is an operation. I assume this BiFunction class was copied across from Lang bringing the noop with it. A minor inconsistency: QueueInputStream uses the new AbstractStreamBuilder API but existing public constructors are not deprecated. However other classes with equally simple constructors (MemoryMappedFileInputStream, MessageDigestCalculatingInputStream, etc) have deprecated their public constructors in favour of the builder. Documentation: The new AbstractStreamBuilder API exposes a lot of public set methods in the builder. Some of these may not be applicable to all use cases. The API allows an object for IO that is typically created with either a Reader/Writer or Input/OutputStream, to also be created with a Path or File. However creation using a Reader does not support InputStream and vice versa. If a Reader is set then the Origin will not be valid and a RTE will occur when opening the object which tries to access the input stream from the Origin. Using the old API of public constructors it was clear what the supported input arguments were. All the Deprecated constructors that reference the new builder would benefit from javadoc on the builder of the valid options that can be configured. The new classes UncheckedBufferedReader, UncheckedFilterInputStream, UncheckedFilterReader, UnsynchronizedBufferedInputStream, UnsynchronizedFilterInputStream, UncheckedFilterOutputStream do not use the AbstractStreamBuilder API and have constructors. I think the API can be applied in these cases, although many of the options would be ignored (e.g. charset, buffer size, etc). However there may be a reason that blocks use of the API that I did not notice (as I did not try to implement it). NullOutputStream deprecated constructor references deprecated NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Following on from this should the NullPrintStream and NullWriter constructors also be deprecated in favour of the INSTANCE?
Re: [CANCEL][VOTE] Release Apache Commons IO 2.12.0 based on RC1
Thanks Rob! Make sure you track git master as I am going through Alex's comments and pushing updates, I should be done tonight. Gary On Wed, May 3, 2023, 08:22 Rob Tompkins wrote: > I was reading this release over yesterday. I’m still looking at the code > changes generally. > > Cheers, > -Rob > > > On May 2, 2023, at 7:31 PM, Gary Gregory wrote: > > > > Great review Alex, TY, I am canceling this vote and will reply to this > > email with details. > > > > Gary > > > > On Tue, May 2, 2023, 12:14 Alex Herbert > wrote: > > > >> Validated signatures and checksums. > >> > >> Build from source tar.gz file using 'mvn verify site' with: > >> > >> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584) > >> Maven home: /usr/local/apache-maven-3 > >> Java version: 11.0.18, vendor: Ubuntu, runtime: > >> /usr/lib/jvm/java-11-openjdk-amd64 > >> Default locale: en_GB, platform encoding: UTF-8 > >> OS name: "linux", version: "5.4.0-148-generic", arch: "amd64", family: > >> "unix" > >> > >> I do see the checkstyle and spotbugs report. > >> > >> Spotbugs has a few mentions of non-serializable fields. This is > >> another case where we may not wish to support serialization going > >> forward (e.g. as with CSV). I cannot remember the solution for CSV. I > >> think it was a formal documentation that serialization will be dropped > >> in CSV 2.0. Looking at the error these are not new as the report in > >> the live site for 2.11.0 also has these. > >> > >> Checked for the @since tag for new items in the japicmp report and > >> found no missing tags. I note that some of the new classes in package > >> io.build have no javadoc on inner classes with public constructors and > >> some static helper protected methods. > >> > >> New helper classes with a private constructor should be final: > >> > >> CharsetDecoders > >> CharsetEncoders > >> FilesUncheck > >> FileTimes > >> > >> Changing public classes to final after a release breaks binary > >> compatibility. However other utility classes in the lib do not use > >> final for classes so this is not critical. FYI there are 5 others > >> which I found using PMD. The rule is > >> ClassWithOnlyPrivateConstructorsShouldBeFinal [1]. This is not part of > >> the default rules used in the project which is using the default from > >> the maven plugin [2]. If you run 'mvn pmd:check' the rules are written > >> to target/pmd/rulesets. I took these rules, added the extra rule and > >> then used this as the ruleset for PMD. > >> > >> The new IOBiFunction has a noop method. This has no equivalent in > >> java.util.function.BiFunction. As discussed on a recent PR for Lang > >> (adding a noop to TriFunction) it does not make sense to have a noop > >> function that returns null as this is an operation. I assume this > >> BiFunction class was copied across from Lang bringing the noop with > >> it. > >> > >> A minor inconsistency: QueueInputStream uses the new > >> AbstractStreamBuilder API but existing public constructors are not > >> deprecated. However other classes with equally simple constructors > >> (MemoryMappedFileInputStream, MessageDigestCalculatingInputStream, > >> etc) have deprecated their public constructors in favour of the > >> builder. > >> > >> Documentation: The new AbstractStreamBuilder API exposes a lot of > >> public set methods in the builder. Some of these may not be applicable > >> to all use cases. The API allows an object for IO that is typically > >> created with either a Reader/Writer or Input/OutputStream, to also be > >> created with a Path or File. However creation using a Reader does not > >> support InputStream and vice versa. If a Reader is set then the Origin > >> will not be valid and a RTE will occur when opening the object which > >> tries to access the input stream from the Origin. Using the old API of > >> public constructors it was clear what the supported input arguments > >> were. All the Deprecated constructors that reference the new builder > >> would benefit from javadoc on the builder of the valid options that > >> can be configured. > >> > >> The new classes UncheckedBufferedReader, UncheckedFilterInputStream, > >> UncheckedFilterReader, UnsynchronizedBufferedInputStream, > >> UnsynchronizedFilterInputStream, UncheckedFilterOutputStream do not > >> use the AbstractStreamBuilder API and have constructors. I think the > >> API can be applied in these cases, although many of the options would > >> be ignored (e.g. charset, buffer size, etc). However there may be a > >> reason that blocks use of the API that I did not notice (as I did not > >> try to implement it). > >> > >> NullOutputStream deprecated constructor references deprecated > >> NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Following on from > >> this should the NullPrintStream and NullWriter constructors also be > >> deprecated in favour of the INSTANCE? > >> > >> New class UncheckedFilterOutputStream has a public constructor but > >> UncheckedFilterWriter is protected. Both
Re: [CANCEL][VOTE] Release Apache Commons IO 2.12.0 based on RC1
I was reading this release over yesterday. I’m still looking at the code changes generally. Cheers, -Rob > On May 2, 2023, at 7:31 PM, Gary Gregory wrote: > > Great review Alex, TY, I am canceling this vote and will reply to this > email with details. > > Gary > > On Tue, May 2, 2023, 12:14 Alex Herbert wrote: > >> Validated signatures and checksums. >> >> Build from source tar.gz file using 'mvn verify site' with: >> >> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584) >> Maven home: /usr/local/apache-maven-3 >> Java version: 11.0.18, vendor: Ubuntu, runtime: >> /usr/lib/jvm/java-11-openjdk-amd64 >> Default locale: en_GB, platform encoding: UTF-8 >> OS name: "linux", version: "5.4.0-148-generic", arch: "amd64", family: >> "unix" >> >> I do see the checkstyle and spotbugs report. >> >> Spotbugs has a few mentions of non-serializable fields. This is >> another case where we may not wish to support serialization going >> forward (e.g. as with CSV). I cannot remember the solution for CSV. I >> think it was a formal documentation that serialization will be dropped >> in CSV 2.0. Looking at the error these are not new as the report in >> the live site for 2.11.0 also has these. >> >> Checked for the @since tag for new items in the japicmp report and >> found no missing tags. I note that some of the new classes in package >> io.build have no javadoc on inner classes with public constructors and >> some static helper protected methods. >> >> New helper classes with a private constructor should be final: >> >> CharsetDecoders >> CharsetEncoders >> FilesUncheck >> FileTimes >> >> Changing public classes to final after a release breaks binary >> compatibility. However other utility classes in the lib do not use >> final for classes so this is not critical. FYI there are 5 others >> which I found using PMD. The rule is >> ClassWithOnlyPrivateConstructorsShouldBeFinal [1]. This is not part of >> the default rules used in the project which is using the default from >> the maven plugin [2]. If you run 'mvn pmd:check' the rules are written >> to target/pmd/rulesets. I took these rules, added the extra rule and >> then used this as the ruleset for PMD. >> >> The new IOBiFunction has a noop method. This has no equivalent in >> java.util.function.BiFunction. As discussed on a recent PR for Lang >> (adding a noop to TriFunction) it does not make sense to have a noop >> function that returns null as this is an operation. I assume this >> BiFunction class was copied across from Lang bringing the noop with >> it. >> >> A minor inconsistency: QueueInputStream uses the new >> AbstractStreamBuilder API but existing public constructors are not >> deprecated. However other classes with equally simple constructors >> (MemoryMappedFileInputStream, MessageDigestCalculatingInputStream, >> etc) have deprecated their public constructors in favour of the >> builder. >> >> Documentation: The new AbstractStreamBuilder API exposes a lot of >> public set methods in the builder. Some of these may not be applicable >> to all use cases. The API allows an object for IO that is typically >> created with either a Reader/Writer or Input/OutputStream, to also be >> created with a Path or File. However creation using a Reader does not >> support InputStream and vice versa. If a Reader is set then the Origin >> will not be valid and a RTE will occur when opening the object which >> tries to access the input stream from the Origin. Using the old API of >> public constructors it was clear what the supported input arguments >> were. All the Deprecated constructors that reference the new builder >> would benefit from javadoc on the builder of the valid options that >> can be configured. >> >> The new classes UncheckedBufferedReader, UncheckedFilterInputStream, >> UncheckedFilterReader, UnsynchronizedBufferedInputStream, >> UnsynchronizedFilterInputStream, UncheckedFilterOutputStream do not >> use the AbstractStreamBuilder API and have constructors. I think the >> API can be applied in these cases, although many of the options would >> be ignored (e.g. charset, buffer size, etc). However there may be a >> reason that blocks use of the API that I did not notice (as I did not >> try to implement it). >> >> NullOutputStream deprecated constructor references deprecated >> NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Following on from >> this should the NullPrintStream and NullWriter constructors also be >> deprecated in favour of the INSTANCE? >> >> New class UncheckedFilterOutputStream has a public constructor but >> UncheckedFilterWriter is protected. Both have a static 'on' method for >> construction so this is inconsistent. These could use the >> AbstractStreamBuilder API although the constructors are very simple. >> Use of the new API would allow use of Path/File as output. >> >> New class ThreadUtils has a TODO in the javadoc. The javadoc also >> requires tags. The TODO can be moved to a method comment rather >>
[CANCEL][VOTE] Release Apache Commons IO 2.12.0 based on RC1
Great review Alex, TY, I am canceling this vote and will reply to this email with details. Gary On Tue, May 2, 2023, 12:14 Alex Herbert wrote: > Validated signatures and checksums. > > Build from source tar.gz file using 'mvn verify site' with: > > Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584) > Maven home: /usr/local/apache-maven-3 > Java version: 11.0.18, vendor: Ubuntu, runtime: > /usr/lib/jvm/java-11-openjdk-amd64 > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "5.4.0-148-generic", arch: "amd64", family: > "unix" > > I do see the checkstyle and spotbugs report. > > Spotbugs has a few mentions of non-serializable fields. This is > another case where we may not wish to support serialization going > forward (e.g. as with CSV). I cannot remember the solution for CSV. I > think it was a formal documentation that serialization will be dropped > in CSV 2.0. Looking at the error these are not new as the report in > the live site for 2.11.0 also has these. > > Checked for the @since tag for new items in the japicmp report and > found no missing tags. I note that some of the new classes in package > io.build have no javadoc on inner classes with public constructors and > some static helper protected methods. > > New helper classes with a private constructor should be final: > > CharsetDecoders > CharsetEncoders > FilesUncheck > FileTimes > > Changing public classes to final after a release breaks binary > compatibility. However other utility classes in the lib do not use > final for classes so this is not critical. FYI there are 5 others > which I found using PMD. The rule is > ClassWithOnlyPrivateConstructorsShouldBeFinal [1]. This is not part of > the default rules used in the project which is using the default from > the maven plugin [2]. If you run 'mvn pmd:check' the rules are written > to target/pmd/rulesets. I took these rules, added the extra rule and > then used this as the ruleset for PMD. > > The new IOBiFunction has a noop method. This has no equivalent in > java.util.function.BiFunction. As discussed on a recent PR for Lang > (adding a noop to TriFunction) it does not make sense to have a noop > function that returns null as this is an operation. I assume this > BiFunction class was copied across from Lang bringing the noop with > it. > > A minor inconsistency: QueueInputStream uses the new > AbstractStreamBuilder API but existing public constructors are not > deprecated. However other classes with equally simple constructors > (MemoryMappedFileInputStream, MessageDigestCalculatingInputStream, > etc) have deprecated their public constructors in favour of the > builder. > > Documentation: The new AbstractStreamBuilder API exposes a lot of > public set methods in the builder. Some of these may not be applicable > to all use cases. The API allows an object for IO that is typically > created with either a Reader/Writer or Input/OutputStream, to also be > created with a Path or File. However creation using a Reader does not > support InputStream and vice versa. If a Reader is set then the Origin > will not be valid and a RTE will occur when opening the object which > tries to access the input stream from the Origin. Using the old API of > public constructors it was clear what the supported input arguments > were. All the Deprecated constructors that reference the new builder > would benefit from javadoc on the builder of the valid options that > can be configured. > > The new classes UncheckedBufferedReader, UncheckedFilterInputStream, > UncheckedFilterReader, UnsynchronizedBufferedInputStream, > UnsynchronizedFilterInputStream, UncheckedFilterOutputStream do not > use the AbstractStreamBuilder API and have constructors. I think the > API can be applied in these cases, although many of the options would > be ignored (e.g. charset, buffer size, etc). However there may be a > reason that blocks use of the API that I did not notice (as I did not > try to implement it). > > NullOutputStream deprecated constructor references deprecated > NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Following on from > this should the NullPrintStream and NullWriter constructors also be > deprecated in favour of the INSTANCE? > > New class UncheckedFilterOutputStream has a public constructor but > UncheckedFilterWriter is protected. Both have a static 'on' method for > construction so this is inconsistent. These could use the > AbstractStreamBuilder API although the constructors are very simple. > Use of the new API would allow use of Path/File as output. > > New class ThreadUtils has a TODO in the javadoc. The javadoc also > requires tags. The TODO can be moved to a method comment rather > than being within the javadoc where I do not think it is beneficial to > the end-user. > > I do not think these are blockers. Extra docs on the use of the > builders can be added later. But it may be nice to clean up little > inconsistencies in the new public before release. > > Alex
