Re: [VOTE] Release Apache Commons IO 2.12.0 based on RC1
Thank you for your detailed review, Alex. Please find my comments embedded below. On 2023/05/02 16:13:31 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. For CSV, we (1) documented serialization as deprecated and (2) only document it as supported within that version, IOW, not between old and new versions. For IO, I have now documented serialization as deprecated as well. I've added the following Javadoc to each class that implements Serializable: "Serialization is deprecated and will be removed in 3.0." There is no way to formally do this since you cannot use @Deprecated for an interface in an "implements" clause. > > 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. Good catch, I've added the missing Javadocs. > > New helper classes with a private constructor should be final: > > CharsetDecoders > CharsetEncoders > FilesUncheck > FileTimes Done. > > 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. I added src/conf/maven-pmd-plugin.xml and the POM now uses it. > > 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. I removed this new API. > > 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. QueueInputStream now deprecates the one-argument constructor. Other classes can implement builders and deprecate constructors at a later time. > > 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. I've added more Javadoc comments and expanded existing Javadocs. > > 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). These classes now use builders. > > NullOutputStream deprecated constructor references deprecated > NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Done. >Following on from >
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 >>
Re: Volunteering
How are you coming with rewriting the unit tests? On Thu, Apr 13, 2023 at 1:05 PM Elric V wrote: > On 10/04/2023 22:31, Miguel Muñoz wrote: > > Elric, > >Did you take up Gary's "thankless" task of updating the tests for > Commons > > VFS? Because I'm looking for a volunteer task, and an opportunity to > > improve my JUnit 5 skills, so I'd be happy to pitch in. > > I've had a quick look at it but ran into some build issues. While > investigating the possible test upgrade, I stumbled upon openrewrite, > which seems to be a tool which could help automate the process, so I'm > slowly tinkering with that. > > There's plenty to be done, so don't feel bad if you beat me to it :D > > Best, > > Elric > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [COLLECTIONS] Trie subclassing
I have a work around but not having to convert from binary representation to string would be handy. But it is not critical. I am also not sure that the API is documented all that well. Perhaps I should open a low level ticket that we can work on after 4.5 is released. On Sun, Apr 23, 2023 at 9:33 PM Gary Gregory wrote: > Claude, > > Do you need the API to be made public? > > Gary > > On Mon, Apr 17, 2023 at 2:53 PM Gary Gregory > wrote: > > > > I am guessing that only what is required to be public is as to both > maximize our flexibility in maintenance and minimize the public API surface > to support. > > > > We could make it public if we are sure the API is documented and the > code isbas good as we can reasonably make it. > > > > Gary > > > > > > On Mon, Apr 17, 2023, 11:48 Claude Warren wrote: > >> > >> I was looking at the Trie and PatriciaTree class structure from version > 4.5 > >> over the weekend. I wanted to build a different implementation with > slight > >> modifications. However, there does not seem to be a way to inherit from > >> AbstractPatriciaTrie as it is package protected. Was this intentional > or > >> just an oversight because there was only one concrete implementation > >> provided? > >> > >> -- > >> LinkedIn: http://www.linkedin.com/in/claudewarren > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- LinkedIn: http://www.linkedin.com/in/claudewarren
