Re: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)
I'm OK with preferring SystemProperties though I'm not sure that
alpine justifies a new method and deprecation.
I second the opinion that a literal string is strongly preferable to a
Supplier here. Pick the simplest thing that could possibly work. As
Knuth warned us, premature optimization is the root of all evil in
programming.
On Wed, May 1, 2024 at 1:56 PM Bernd Eckenfels wrote:
>
> Hi Gregory,
>
> What’s the idea behind that deprecation? The implementation is robust and
> simple and easy to use. I would guess most user rather want to specify a
> literal fallback than a supplier.
>
> Gruss
> Bernd
>
> ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > Author: Gary Gregory
> > AuthorDate: Wed May 1 09:12:09 2024 -0400
> >
> > Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier)
> > ---
> > src/changes/changes.xml | 1 +
> > src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index cdd3a0cd0..1d896a999 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -123,6 +123,7 @@ The type attribute can be
> > add,update,fix,remove.
> > Fix Java version in README.md #1170.
> > StringUtils.stripAccents() should handle
> > ligatures, UTF32 math blocks, etc. #1201.
> > > due-to="kijong.youn, Aakash Gupta, Gary
> > Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > class in the inner class parameterized enclosing class #657.
> > +Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier).
> >
> > > due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > > due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > 3.1.1 to 3.2.0 #1175.
> > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > index cbb4721fb..8044fd4b0 100644
> > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > @@ -17,6 +17,7 @@
> > package org.apache.commons.lang3;
> >
> > import java.io.File;
> > +import java.util.function.Supplier;
> >
> > /**
> > * Helpers for {@link System}.
> > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > * access to the specified system property.
> > * @see SystemProperties#getUserName()
> > * @since 3.10
> > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > */
> > +@Deprecated
> > public static String getUserName(final String defaultValue) {
> > return System.getProperty(SystemProperties.USER_NAME,
> > defaultValue);
> > }
> >
> >
>
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] GitHub is done with Java 8
That's surprising. What's the context for this? Github actions? On Wed, Apr 24, 2024 at 9:57 AM Gary D. Gregory wrote: > > Hi All, > > I just saw this on GitHub for our Lang component: > > Error: Could not find satisfied version for SemVer '8'. > > Available versions: 22.0.1+8, 22.0.0+36, 21.0.3+9.0.LTS, 21.0.2+13.0.LTS, > 21.0.1+12.0.LTS, 21.0.0+35.0.LTS, 20.0.2+9, 20.0.1+9, 20.0.0+36, 19.0.2+7, > 19.0.1+10, 19.0.0+36, 18.0.2+101, 18.0.2+9, 18.0.1+10, 18.0.0+36, 17.0.11+9, > 17.0.10+7, 17.0.9+9, 17.0.8+101, 17.0.8+7, 17.0.7+7, 17.0.6+10, 17.0.5+8, > 17.0.4+101, 17.0.4+8, 17.0.3+7, 17.0.2+8, 17.0.1+12, 17.0.0+35, 11.0.23+9, > 11.0.22+7.1, 11.0.22+7, 11.0.21+9, 11.0.20+101, 11.0.20+8, 11.0.19+7, > 11.0.18+10, 11.0.17+8, 11.0.16+101, 11.0.16+8, 11.0.15+10 > > So it looks like goodbye Java 8 on GitHub. > > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections]
On Tue, Apr 9, 2024 at 11:09 PM Rodion Efremov wrote: > > Hello, > > Fair enough. However, why we have CursorableLinkedList and > NodeCachingLinkedList around when my previous benchmarking showed that they > are inferior compated to both TreeList and IndexedLinkedList? We have a lot of things we don't need and that shouldn't be used. It happens sometimes on long lived bazaar-style projects without a clear vision and maintainer. If those two classes are demonstrably inferior, it might be worthwhile deprecating them. Meanwhile I'd prefer not to make the situation worse. We already have more code than we can maintain, and are wasting a lot of dev cycles on idiosyncratic churn to no good end. > Also, note that TreeList requires 3 references, 2 ints and 2 booleans per > node. IndexedLinkedList requires only 3 references per node. > > If you need benchmarking on small lists, just tell me and I will arrange > that. Lies, damned lies, and benchmarks. :-) Benchmarking is hard and rarely matches reality. By coincidence, I spent last week learning about the damage the TPCH benchmarks do in the database space. The benchmarks that matter are profiles of real world applications, and every application is different. Better algorithms are sometimes discovered, even for well trod territory like lists, but typically they only improve performance in the limit and often decrease performance in real world applications. Looking at the repo, this seems to be a newly constructed data structure. I suggest cleaning up the blog post and submitting it to an appropriate peer reviewed journal in the field and posting the preprint on arxiv so true experts can take a look. (I'm just a practitioner.) If the data structure proves out over time in real world use cases, then it should be considered for Apache Commons. However, I don't think Commons is the right place for bleeding edge research. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections]
How does it compare to a simple array or ArrayList? Given modern CPU architecture and caching, I rarely encounter real world use cases where a linked list outperforms an array list, no matter what the data structures textbooks say. Maybe on very large lists with a lot of mutations, though last I checked the size where this came into play was 100K elements and growing. Maybe your algorithm is faster. I don't know. https://www.reddit.com/r/learnprogramming/comments/10hwrmy/why_arent_linked_lists_more_popular/ On Tue, Apr 9, 2024 at 9:01 AM Rodion Efremov wrote: > > Good day, > > I would like to propose a Deque/List that is implemented as a doubly linked > list with a sublinear index speeding up single-element operations to > (likely) O(sqrt(n)). It passes a benchmark faster than TreeList by the > factor of around 5. > > The data structure is hosted in GitHub: > https://github.com/coderodde/IndexedLinkedList > > Does it have potential to be included in Collections? > > Best regards, > rodde -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LEGACY STAT] test suite from legacy includes non-free NIST data
This is something to ask Apache lawyers about. Yes, we're allowed to distribute this public US government data. No, that doesn't mean we can distribute it under the Apache license. Do we claim this is under the Apache license? I can't tell. The legal nitpicking is beyond me. On Tue, Mar 26, 2024 at 10:46 PM Orion Yeung wrote: > > Hello, > > I was unsure how to identify the component in the subject header here, but > I'd noticed you've got the standard reference NIST data in your repo, here: > > https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data > > that we - on a statistics Rust crate - realized we needed to stop > redistributing in our repo. *I'm not a legal person, but I'm providing the > heads up as it may be a copyright violation. *Feel free to ask me for > clarifications. > > Some relevant links, > > [Fedora mailing list discussing this data when using the crate] ( > https://lists.fedoraproject.org/archives/list/legal%40lists.fedoraproject.org/thread/LSM6MO6TAHTIDNF5COCA6UWQDHWRF3AH/ > ) > [statrs GitHub issue mentioning this]( > https://github.com/statrs-dev/statrs/issues/195) > > Best, > -- > Orion Yeung > he / him -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Logging 1.3.1 based on RC2
coding: UTF-8 > > > OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac" > > > > > > Darwin 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58 > > > PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64 > > > > > > Details of changes since 1.3.0 are in the release notes: > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/RELEASE-NOTES.txt > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/site/changes-report.html > > > > > > Site: > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/site/index.html > > >(note some *relative* links are broken and the 1.3.1 directories > > > are not yet created - these will be OK once the site is deployed.) > > > > > > *** CLIRR Report (compared to 1.3.0): > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/site/clirr-report.html > > > > > > *** JApiCmp Report (compared to 1.3.0): > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/site/japicmp.html > > > > > >*** > > >Note that the above report notes several errors. > > >These are considered OK for the reasons stated below. > > >These exceptions are also noted in the Changes and Release Notes. > > > > > >Errors reported: > > >- methods added to interface: OK because that does not affect > > > binary compatibility. > > >- etc. > > >*** > > > > > > RAT Report: > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/site/rat-report.html > > > > > > KEYS: > > > https://downloads.apache.org/commons/KEYS > > > > > > Please review the release candidate and vote. > > > This vote will close no sooner than 72 hours from now. > > > > > > [ ] +1 Release these artifacts > > > [ ] +0 OK, but... > > > [ ] -0 OK, but really should fix... > > > [ ] -1 I oppose this release because... > > > > > > Thank you, > > > > > > Gary Gregory, > > > Release Manager (using key 86fdc7e2a11262cb) > > > > > > For following is intended as a helper and refresher for reviewers. > > > > > > Validating a release candidate > > > == > > > > > > These guidelines are NOT complete. > > > > > > Requirements: Git, Java, Maven. > > > > > > You can validate a release from a release candidate (RC) tag as follows. > > > > > > 1a) Clone and checkout the RC tag > > > > > > git clone https://gitbox.apache.org/repos/asf/commons-logging.git > > > --branch commons-logging-1.3.1-RC2 commons-logging-1.3.1-RC2 > > > cd commons-logging-1.3.1-RC2 > > > > > > 1b) Download and unpack the source archive from: > > > > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.1-RC2/source > > > > > > 2) Check Apache licenses > > > > > > This step is not required if the site includes a RAT report page which > > > you then must check. > > > > > > mvn apache-rat:check > > > > > > 3) Check binary compatibility > > > > > > Older components still use Apache Clirr: > > > > > > This step is not required if the site includes a Clirr report page > > > which you then must check. > > > > > > mvn clirr:check > > > > > > Newer components use JApiCmp with the japicmp Maven Profile: > > > > > > This step is not required if the site includes a JApiCmp report page > > > which you then must check. > > > > > > mvn install -DskipTests -P japicmp japicmp:cmp > > > > > > 4) Build the package > > > > > > mvn -V clean package > > > > > > You can record the Maven and Java version produced by -V in your VOTE > > reply. > > > To gather OS information from a command line: > > > Windows: ver > > > Linux: uname -a > > > > > > 5) Build the site for a single module project > > > > > > Note: Some plugins require the components to be installed instead of > > packaged. > > > > > > mvn site > > > Check the site reports in: > > > - Windows: target\site\index.html > > > - Linux: target/site/index.html > > > > > > -the end- > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Interest in CollectionUtils feature
At first glance, my impression is that this need isn't common or complex enough to justify inclusion. It could probably be straight-forwardedly implemented with lambdas by someone who does need it. That said, if it is added, the signature should probably be CollectionUtils.firstNonEmpty(Collection... collection) for more generality and use. Also NotEmpty --> NonEmpty On Wed, Mar 20, 2024 at 8:28 AM Marco Dell'Anna wrote: > > Hi, > I would like to have a CollectionUtils.firstNotEmpty(List... lists) method. > Since commons-collections/CONTRIBUTING.md at master · > apache/commons-collections · GitHub > <https://github.com/apache/commons-collections/blob/master/CONTRIBUTING.md> > says: > * If you're planning to implement a new feature it makes sense to discuss > your changes on the dev list first. This way you can make sure you're not > wasting your time on something that isn't considered to be in Apache > Commons Collections's scope. > I'm asking if I should create a Merge Request > > Thanks > Marco Dell'Anna -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Logging 1.4.0 based on RC1
You don't have to accept the PRs, but they should be addressed. If the logback PR requires Java 11, then close it (and maybe check to see if there's something in between 1.3.12 and 1.5.3 that logging should upgrade to instead). If logkit isn't going to be supported, cool, but then close the PR and delete the dependency and all code that needs it. Address the other four open PRs as each requires. It is important to address PRs and triage issues regularly, and certainly before any non-patch, non-emergency release. IMHO lack of issue triage and PR review is a very good indicator that a project is not safe to release. On Sun, Mar 17, 2024 at 12:45 PM Gary Gregory wrote: > > For example? The Logback PR requires Java 11. What else? Logkit? Maybe but > I've never heard anyone ask for that. > > Projects have open PRs all the time for dependencies or other reasons, > that's no reason to downvote a release candidate IMO. I prefer RERO to > bigger releases FWIW. > > Gary > > On Sun, Mar 17, 2024, 8:05 AM Elliotte Rusty Harold > wrote: > > > -1 > > > > There are multiple open PRs waiting for review, including apparently > > two to upgrade the dependent logging libraries this library is a > > facade over, wh9ich seem pretty important. These should be resolved > > before cutting the next release. > > > > On Sun, Mar 17, 2024 at 11:49 AM Gary Gregory > > wrote: > > > > > > We have fixed a few bugs and added some enhancements since Apache > > > Commons Logging 1.3.0 was released, so I would like to release Apache > > > Commons Logging 1.4.0. > > > > > > Apache Commons Logging 1.4.0 RC1 is available for review here: > > > https://dist.apache.org/repos/dist/dev/commons/logging/1.4.0-RC1 > > > (svn revision 67977) > > > > > > The Git tag commons-logging-1.4.0-RC1 commit for this RC is > > > ac55303ba66dc0046f6118f74eecd46c74eeeb4a which you can browse here: > > > > > https://gitbox.apache.org/repos/asf?p=commons-logging.git;a=commit;h=ac55303ba66dc0046f6118f74eecd46c74eeeb4a > > > You may checkout this tag using: > > > git clone https://gitbox.apache.org/repos/asf/commons-logging.git > > > --branch commons-logging-1.4.0-RC1 commons-logging-1.4.0-RC1 > > > > > > Maven artifacts are here: > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1703/commons-logging/commons-logging/1.4.0/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Sun Mar 17 11:41:39 UTC 2024 > > > > > commons-logging-1.4.0-sources.jar=5e71710bec4a5a86efffd32da7460a8cad072732287a243c936d6cdc27115823526278cea8f469ff2108a0d0b07cd54e97edd35c252b7ea706cede65051ad8bf > > > > > commons-logging-1.4.0-src.zip=937f21c05d386733e1ba41cd3f655518799b4155d22884e0a180730df12c9192cfd29e47991a5178ac56db74645a25074ea609cfa34ae5796ae52ba9361b > > > > > commons-logging-1.4.0-tests.jar=9546b9d8b0af2ae349eb05f0613036798d6172f055bebd337846a0baa18fd26a4136381cdf22583b473d2e3d838da9ca4351b01f75350b78f1b265d96fe403d7 > > > > > commons-logging-1.4.0-bom.json=f0a6d8241df605eb658679aa2668d3fa884b6cd5632bc11fe0467a22e9d321dc4a273fb996281ef8228ae9db89a18e268c9825d9f02deb707842fd51157b3b24 > > > > > commons-logging-1.4.0-javadoc.jar=2defa71a19149811f7ecf1e5bf66508ac684641afb78ae8fd54dd4ac68a5f186d9ea44364b6171ee683cb9fe01f97908ca1a7c2d14b9cdd451330d9dc3f00ac4 > > > > > commons-logging-1.4.0-api.jar=4874cbcda59f70e66ff1596e27a56df4f0ff8b37dfc97c5cf4cdccbe1f54ebbed68d3c920f45ab2d9baf3a22117c3adb2cc3a1c8df539f61a4c31b26f0ca49ed > > > > > commons-logging-1.4.0-src.tar.gz=bfe6a392ce9990c686c1e14a4c23f5a4251e2614a3a07d7afb5b5052e182ae14596b19b4176afa15d6d750ba603a6fc9ec1015d3ce08c98ab3b545daf471125e > > > > > commons-logging-1.4.0-bin.tar.gz=22df1b2963df0c35ce3fea7f35602a4af8ace5c74079f696480e601700ef8b15703d5011de5fbc10aea74f8b1f73f96a07d519839f40e38c6bc2daf918b6c520 > > > > > commons-logging_commons-logging-1.4.0.spdx.json=e4a5ddda46381f31a3ef506fab4e02c4ec952094ea70dc6209c6ed27bb7a941d13491762f1546d53ce09a3eb64ffb5cd406c12dd44d5efb1bbe4c7ee3e8cbde6 > > > > > commons-logging-1.4.0-test-sources.jar=06239eb9bb64e28f6b835a4b55479d9637f597e9c114070f2bf5243f2a82f656b03dca54f64cd89589d2d1cf789b56c99cc45f0cb578d7b6ef100b2a8cbbd512 > > > > > commons-logging-1.4.0-bom.xml=e15f5ff2bc7b7416fe83ee91f1cd7b7e18cab58135e644716ca2e7bbe871668283c5c16faef8faa04f1632d3bf994772ac3a68c8dbd20ae2835429c482e2ca22 > > > > > commons-logging-1.4.0-bin.zip=80639fe769a95f8b810983de1e21fd3cfb0efd9931c07cd21e206c1a80c06fd98223cbb0afe6189b6daa256fc49fff8d
Re: [VOTE] Release Apache Commons Logging 1.4.0 based on RC1
; JApiCmp Report (compared to 1.3.0): > > https://dist.apache.org/repos/dist/dev/commons/logging/1.4.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/logging/1.4.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-logging.git > --branch commons-logging-1.4.0-RC1 commons-logging-1.4.0-RC1 > cd commons-logging-1.4.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/logging/1.4.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
On Tue, Feb 27, 2024 at 1:43 PM Piotr P. Karwasz wrote: > > Hi Elliotte, > > On Tue, 27 Feb 2024 at 13:20, Elliotte Rusty Harold > wrote: > > > > On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz > > wrote: > > e will not be loaded even if it is available. > > > > > > Fortunately Commons Compress is well-engineered and easy to split. The > > > code that depends on: > > > > What about creating: > * separate `commons-compress-zstd`, `commons-compress-brotli`, > `commons-compress-pack200`, `commons-compress-xz` artifacts with the > packages that require external dependencies, > * a new `commons-compress-core` (or `-api` and `-impl`) with the rest > of the code, > * an empty `commons-compress` artifact with a hard dependency on the > remaining ones. It just needs a JPMS module descriptor with `requires > transitive` directives to the other modules. > > This way won't have problems when they automatically upgrade > `commons-compress`. They'll just end up with many additional > dependencies. > I'm not quite sure what you're proposing. This works if you also change the package to something like org.apache.commons.compress2. It does not work without changing the package names. The bottom line is: 1. A classpath MUST NOT have the same fully package qualified name in more than one JAR. This is a hard requirement in Java 9+ with JPMS. The JVM will not run a program that violates this. It is a very important requirement in Java 8. 2. Maven and Gradle cannot resolve dependency conflicts between jars with different groupID:artifactID. They both treat them as fully independent artifacts, even if they're not, and will add both to a classpath, thereby violating rule #1. Consequently if a widely used low level library like commons-compress ships two different artifacts (i.e. different groupId:artifactID) that both contain com.example.package.ClassName, it breaks dependents in hard to debug, hard to work around ways. It is a painful and confusing problem that is often hidden behind multiple levels of transitive dependencies. This can happen even in projects that don't directly depend on commons-compress at all. commons-compress is not a green field. It MUST NOT break existing clients by releasing new jars that split packages in existing classpaths. There are only two options: 1. Change Maven coordinates AND package names 2. Keep Maven coordinates AND package names. More detailed discussion of this at: https://jlbp.dev/JLBP-5 https://jlbp.dev/JLBP-6 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz wrote: e will not be loaded even if it is available. > > Fortunately Commons Compress is well-engineered and easy to split. The > code that depends on: > > * com.github.luben:zstd-jni, > * org.brotli:dec, > * org.ow2.asm:asm, > * org.tukaani:xz. > > is already nicely separated in packages. IMHO those packages could be > moved to separate artifacts **without** requiring a major version bump I wish. It's not that commons-compress is badly factored. It's that Maven and Java don't really allow for compatible upgrades that split existing artifacts into new artifacts. This causes big, hard-to-debug runtime failures. The problem is bad in Java 8 and earlier. It got much worse in Java 9+ with JPMS. The only compatible path that splits artifacts is to rename both the Maven coordinates AND the packages. Otherwise there will be multiple copies of the same class in the classpath, and either the wrong one will be chosen some of the time causing hard to debug runtime failures or (with JPMS) the JVM will simply refuse to run the program at all. What you describe is a good greenfield plan, but it's not a compatible upgrade, not even with a major version update. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
It looks like this has been partially fixed at head. The Maven dependency on commons-io is no longer marked as optional. However the OSGI dependencies are still optional. It's been a few years since I last had to think about OSGI. I'm not sure if this is likely to break anyone or not. On Sat, Feb 24, 2024 at 2:16 PM Elliotte Rusty Harold wrote: > > FYI optional dependency on commons-io is also breaking dependents: > > https://github.com/apache/maven-assembly-plugin/pull/187#pullrequestreview-1899505395 > > These dependencies really shouldn't be optional. > > On Thu, Feb 22, 2024 at 12:08 PM Andrew Coates > wrote: > > > > Hi all, > > > > I'm seeing a runtime failure using TarArchiveOutputStream when updating to > > commons-compress 1.26.0. > > > > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets > > at org.apache.commons.compress@1.26.0 > > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212) > > at org.apache.commons.compress@1.26.0 > > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157) > > at org.apache.commons.compress@1.26.0 > > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147) > > at testcontainers@1.19.5 > > /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350) > > ... > > > > Commons-compress 1.26.0 contains changes to make use of commons-codec, > > rather than its own copy of files, but I see that the POM marks > > commons-codec as *optional*. Excuse my potential ignorance, but I thought > > optional dependencies shouldn't cause runtime failures if not present. Is > > this not the case? > > > > Obviously, I can just add commons-codec as an explicit dependency. But this > > seems wrong IMHO. > > > > Should I sign up for an account and raise this as a bug in Jira? > > > > Thanks, > > > > Andy > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
FYI optional dependency on commons-io is also breaking dependents: https://github.com/apache/maven-assembly-plugin/pull/187#pullrequestreview-1899505395 These dependencies really shouldn't be optional. On Thu, Feb 22, 2024 at 12:08 PM Andrew Coates wrote: > > Hi all, > > I'm seeing a runtime failure using TarArchiveOutputStream when updating to > commons-compress 1.26.0. > > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets > at org.apache.commons.compress@1.26.0 > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212) > at org.apache.commons.compress@1.26.0 > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157) > at org.apache.commons.compress@1.26.0 > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147) > at testcontainers@1.19.5 > /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350) > ... > > Commons-compress 1.26.0 contains changes to make use of commons-codec, > rather than its own copy of files, but I see that the POM marks > commons-codec as *optional*. Excuse my potential ignorance, but I thought > optional dependencies shouldn't cause runtime failures if not present. Is > this not the case? > > Obviously, I can just add commons-codec as an explicit dependency. But this > seems wrong IMHO. > > Should I sign up for an account and raise this as a bug in Jira? > > Thanks, > > Andy -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
On Thu, Feb 22, 2024 at 2:07 PM Romain Manni-Bucau wrote: > +1 Elliotte > ...plus the fact [io] is optional in the pom too which is not correct. Possibly commons-io used to be more legitimately optional, but since a lot of things like CountingOutputStream have now moved into commons-io it really isn't. Is there anywhere explicit documentation of what dependencies commons-compress uses? It is really helpful for clients when libraries make a strong effort to avoid unnecessary dependencies. I can sort of see that a library like compress might depend on lang3 and io, but it would be better if it didn't. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.
Looks like this was fixed at head a few days ago by using Charsets from commons-io instead of commons-codec, and will be in 1.26.1. That said, I don't really like the fix that was committed. The use of the Charsets class here is trivial and should simply be inlined. It's not sufficient reason to pull in an external Charsets class from either commons-codec or commons-io. On Thu, Feb 22, 2024 at 7:08 AM Andrew Coates wrote: > > Hi all, > > I'm seeing a runtime failure using TarArchiveOutputStream when updating to > commons-compress 1.26.0. > > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets > at org.apache.commons.compress@1.26.0 > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212) > at org.apache.commons.compress@1.26.0 > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157) > at org.apache.commons.compress@1.26.0 > /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147) > at testcontainers@1.19.5 > /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350) > ... > > Commons-compress 1.26.0 contains changes to make use of commons-codec, > rather than its own copy of files, but I see that the POM marks > commons-codec as *optional*. Excuse my potential ignorance, but I thought > optional dependencies shouldn't cause runtime failures if not present. Is > this not the case? > > Obviously, I can just add commons-codec as an explicit dependency. But this > seems wrong IMHO. > > Should I sign up for an account and raise this as a bug in Jira? > > Thanks, > > Andy -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
The problem with CTR (Commit Then Review) instead of RTC (Review Then Commit) is that CTR too often turns into Commit Never Review. The problem with RTC is that it slows code velocity. For major projects at the base of a lot of the Java ecosystem like many Apache Commons libraries, I'm willing to accept a slowdown in order to ensure that all changes are reviewed by someone. On Sun, Feb 18, 2024 at 9:51 AM Gary Gregory wrote: > > On Sun, Feb 18, 2024 at 1:22 PM Elliotte Rusty Harold > wrote: > > > > Meta issue: the use of direct git commits without PRs or code review > > makes releases harder to review. > > Hello Elliotte, > > Meta issue: > - This project uses CTR, not RTC. We welcome PRs but do not _require_ > them of project committers. > - Just so you know, for this release, there are other moving parts, > please feel free to contact me privately. > > > > > Specific issues: > > > > https://github.com/apache/commons-compress/commit/9f2f97925fdb52b5a3a32da6337ea1f113a3be82 > > is wonky and rates a -1 from me. An encoding error is not necessarily > > an I/O error, and It's arguably not a backwards compatible change to > > make Pack200Exception iextend IOException instead of Exception. > > I went back and forth and settled on subclassing because: > - When decoding (or encoding), I want to say that something went wrong > _as part of decoding input bits_ (or encoding), and that's working > with Input (or Output), and in my mind that is a kind of IO, Pack200 > IO. > - There are a lot of precedents, some in the JDK, some in other > projects, for IOException subclasses used when parsing input. > - It makes other changes simpler. > - It is binary-compatible per the JLS > (https://docs.oracle.com/javase/specs/jls/se21/html/jls-13.html#jls-13.4) > - JApiCmp verifies this is binary-compatible. > > > > > There seem to have been a lot of needless deprecations of constructors > > and replacement with builder patterns. > > The use of the builder pattern avoids constructor inflation. For > example, we had fourteen (14) constructors for ZipFile, that's > confusing and cluttered, a builder is simpler IMO. > > E.g. in > > https://github.com/apache/commons-compress/commit/b7ba0ced5c950e59214329ae7b102783a5807d2c > > I'll need to look closer to see if these have the same bugs I've seen > > when the same thing was done in commons-IO, but at the absolute least > > it makes the API more complex and less clear. > > > > -10 > > Wow, I'm not sure what to say. You win? Over the top much? How about a > 10-character word: hyperbolic ;-) > > Gary > > > > > On Sat, Feb 17, 2024 at 7:15 PM Gary Gregory wrote: > > > > > > [VOTE] Release Apache Commons Compress 1.26.0 based on RC1 > > > > > > We have fixed a few bugs and added some enhancements since Apache > > > Commons Compress 1.25.0 was released, so I would like to release > > > Apache Commons Compress 1.26.0. > > > > > > Apache Commons Compress 1.26.0 RC1 is available for review here: > > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1 > > > (svn revision 67401) > > > > > > The Git tag commons-compress-1.26.0-RC1 commit for this RC is > > > acaf5642b1e16d872870a4dc4618e46ccd349493 which you can browse here: > > > > > > https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=acaf5642b1e16d872870a4dc4618e46ccd349493 > > > You may checkout this tag using: > > > git clone https://gitbox.apache.org/repos/asf/commons-compress.git > > > --branch commons-compress-1.26.0-RC1 commons-compress-1.26.0-RC1 > > > > > > Maven artifacts are here: > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1689/org/apache/commons/commons-compress/1.26.0/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Sat Feb 17 23:50:41 UTC 2024 > > > commons-compress-1.26.0-bom.xml=30154dabf68fe1d9dfcfb02a9e4d80a4aadd182817c310900178ebae8df06fce23a30b269f63c37fc3a69c59fd57e0d9a9cdc86cddb38ca4d53617f6f6c0da7e > > > commons-compress-1.26.0-javadoc.jar=b08f5b9433e8f7a67b40920a35188cf47a7cc1dfb52e4e9ad196cd445cf2a0737fd8c7d292f6dfb5e4e37f88b44bd902e0180918201eefa8acce27788a295864 > > > commons-compress-1.26.0-src.tar.gz=9348e2792d67fe977cbfcede80ab95de96e582c3f7239e16e99360decac4e7703f57d4cfec9535cd4a0f884319df851eb5e44214ba8c3dd321cc6ea67f9d1abb > > > commons-compress-1.26.0-bin.z
Re: [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
On Sun, Feb 18, 2024 at 9:51 AM Gary Gregory wrote:
> > There seem to have been a lot of needless deprecations of constructors
> > and replacement with builder patterns.
>
> The use of the builder pattern avoids constructor inflation. For
> example, we had fourteen (14) constructors for ZipFile, that's
> confusing and cluttered, a builder is simpler IMO.
>
I don't find constructor inflation to be a problem when the
constructors are obvious alternatives. Look at it from the perspective
of a client of the API rather than an implementer of the API. I just
type
ZipFile z = new ZipFile(myFileObject);
Done. This is simpler to remember, write, and read than
ZipFile z = ZipFile.builder().setFile(myFileObject).build();
If that's even the variant of the builder pattern used here. Every
builder is a little different. It might be
ZipFile z = (new ZipFile.Builder()).setFile(myFileObject).build();
or perhaps
ZipFile z = ZipFile.builder().withFile(myFileObject).build();
or even
ZipFile z = ZipFile.builder().file(myFileObject).build();
There are others. Everyone understands constructors and knows what API
to expect. Builders, not so much.
Using constructors also avoids unexpected runtime exceptions like
https://issues.apache.org/jira/projects/IO/issues/IO-830 and
https://issues.apache.org/jira/projects/IO/issues/IO-831. Example in
this case
ZipFile z = ZipFile.builder()
.setFile(myFileObject)
.setName("myFile.zip")
.setPath(Paths.get("/tmp/anotherfile.zip"))
build();
There isn't a constructor equivalent of this statement because you
can't pass a file and a path and a name to one ZipFile constructor.
With constructors, there's no bug and on runtime problems. Type
checking verifies that the object has the necessary information for a
new object at compile time. With builders you don't find out till
runtime.
Builders do have a place. In particular they are useful when:
1. There are multiple arguments of the same type that are easily confused.
OR
2. Object initialization requires a lot of work that doesn't belong in
a constructor, like reading a file.
AND
3. All arguments not passed to the builder's own constructor are optional.
AND
4. Any combination and permutation of setter methods is allowed.
None of those apply to a straightforward class like ZipFile.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Compress 1.26.0 based on RC1
dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/index.html > (note some *relative* links are broken and the 1.26.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.25.0): > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-compress.git > --branch commons-compress-1.26.0-RC1 commons-compress-1.26.0-RC1 > cd commons-compress-1.26.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-net] issue: FTP other HTTP with Proxy-Authorization fail
Be careful with this one. I don't have full context, but this looks
likely to be a real bug on some code paths and perhaps not a bug on
others. We'll need to make sure that the patch for the broken code
path doesn't break a currently working path. Specifically I'm worried
about where \r\n might and might not show up after the if block shown
here.
On Mon, Feb 12, 2024 at 10:15 AM Емельянов Юрий Владимирович
wrote:
>
> see FTPHTTPClient.tunnelHandshake
>
> current code is:
>
> if (proxyUsername != null && proxyPassword != null) {
> final String auth = proxyUsername + ":" + proxyPassword;
> final String header = "Proxy-Authorization: Basic " +
> Base64.getEncoder().encodeToString(auth.getBytes(charset));
> output.write(header.getBytes(charset));
> }
> correct code is:
>
> if (proxyUsername != null && proxyPassword != null) {
> final String auth = proxyUsername + ":" + proxyPassword;
> final String header = "Proxy-Authorization: Basic " +
> Base64.getEncoder().encodeToString(auth.getBytes(charset));
> output.write(header.getBytes(charset));
> *output.write(CRLF);*
> }
>
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
I'm fine with #1 or #2 if you can make either work. I actively dislike #3. In particular I do not think we should change package names or Maven coordinates. I think it is OK and in this case highly advisable to break API compatibility solely by removing support for obsolete and mostly unused functionality. It is much more important to keep the API for the actively and widely used API intact. That includes package names and Maven coordinates. Changing these makes upgrading to the newer version far more burdensome. Many projects won't do it, and most won't do it quickly. #4 strikes me as excessively nit-picky. If you're going to turn all methods into no-ops, you might as well remove the API. At least then clients of these APIs know their code is broken. Log4J 1.x is not the only thing we need to cut out. We also need to remove AvalonLogger and Jdk13LumberjackLogger, but if you can remove log4j 1.x in commons-logging 1.4 without breaking things that's a step in the right direction. Otherwise, I propose dropping AvalonLogger, Jdk13LumberjackLogger, and Log4jLogger; and shipping what's left as 2.0. On Sat, Feb 10, 2024 at 4:27 PM Gary Gregory wrote: > > Hi All: > > I want to focus on content before we decide what label to put on the > next release. Then, we can see if we want to break binary > compatibility (BC) for a Commons Logging 2.0.0. > > My main driver for the next version is to drop support and dependency > on the Log4j 1.x JARs file(s). I speak of JAR files here as opposed to > APIs, see below. > > I see several ways to drop Log4j 1.x JARs. > 1) Replace the dependency on Log4j 1.x with the Log4j 2 compatibility > JAR for 1.2: org.apache.logging.log4j:log4j-1.2-api > This maintains BC and can become 1.4.0. > 2) A re-implementation of Log4JLogger where all methods call Log4j 2 APIs. > This maintains BC and can become 1.4.0. > It looks like this is not possible in a straightforward manner > because we have Log4j 1 classes in the public API, specifically > org.apache.commons.logging.impl.Log4JLogger.Log4JLogger(Logger). It > might not be worth hacking around that if that's even possible. > 3) A hard delete of org.apache.commons.logging.impl.Log4JLogger (the > class is deprecated in 1.3.0 FWIW). > This breaks BC and requires a 2.0.0 with a package name and Maven > coordinate change. > The package would change from org.apache.commons.logging to > org.apache.commons.logging2. > The Maven coordinates would change from > commons-logging:commons-logging to org.apache.commons:commons-logging2 > 4) A gutting of Log4JLogger where all methods are no-ops. > This maintains BC and can become 1.4.0. > > I like (1) the best, it gives us a clear path to a 1.4.0 without > breaking BC and removes dependencies on the 1.x jars. > From my POV breaking BC in Logging 1.x is a non-starter. > > Then, if we want to remove support for the Log4j 1 API (the JAR is > already gone at this point), that would necessitate a 2.0.0. > > Gary > > On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold > wrote: > > > > I'd like to plan and start working on a 2.0 release of commons-logging > > with the specific goal of resolving the large number of out of date, > > unsupported, old libraries that this project pulls into so many > > dependency trees. There's been some discussion of a 2.0 release in > > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > > but I'd lik to bring this to a wider audience. Specifically my > > thoughts are: > > > > 1. 2.0 will be technically API incompatible since it will remove all > > traces of EOL libraries like log4j 1.x and avalon. > > 2. It will otherwise be a drop-in replacement for anyone not using > > these old libraries. Specifically: > > * Other deprecated methods are not removed. > > * The package name does not change. > > * The group ID and artifact ID do not change. > > * Minimum Java version remains 1.8 > > 3. It can include any recent, API compatible bug fixes and new > > features that are available at HEAD, but these are not blockers. > > > > While there are other more incompatible changes that could be made in > > a major version bump, I think it's really important to produce a > > drop-in replacement that is friendlier to security scanners and > > dependency analyzers. I do not want to discourage people from > > upgrading for any reason other than they're still using EOL libraries > > like log4j 1.x. > > > > 1.3.0 was recently released and seems up to date with the last several > > years of changes and bugs, so it feels like a good time to make the > > break. Anyone who isn't ready to give up their decade+ old loggers
[LOGGING] 2.0
I'd like to plan and start working on a 2.0 release of commons-logging with the specific goal of resolving the large number of out of date, unsupported, old libraries that this project pulls into so many dependency trees. There's been some discussion of a 2.0 release in JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 but I'd lik to bring this to a wider audience. Specifically my thoughts are: 1. 2.0 will be technically API incompatible since it will remove all traces of EOL libraries like log4j 1.x and avalon. 2. It will otherwise be a drop-in replacement for anyone not using these old libraries. Specifically: * Other deprecated methods are not removed. * The package name does not change. * The group ID and artifact ID do not change. * Minimum Java version remains 1.8 3. It can include any recent, API compatible bug fixes and new features that are available at HEAD, but these are not blockers. While there are other more incompatible changes that could be made in a major version bump, I think it's really important to produce a drop-in replacement that is friendlier to security scanners and dependency analyzers. I do not want to discourage people from upgrading for any reason other than they're still using EOL libraries like log4j 1.x. 1.3.0 was recently released and seems up to date with the last several years of changes and bugs, so it feels like a good time to make the break. Anyone who isn't ready to give up their decade+ old loggers can stay on this release for a while. However if there's a strong need to maintain a 1.x branch that could be done too. Or we could start 2.x as a separate branch. If this achieves rough consensus, I can start sending PRs. However, the final release would require a commons committer or perhaps PMC member to take over. Thoughts? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.16.1 based on RC1
Not sure, but it looks like CODEC-263 https://issues.apache.org/jira/projects/CODEC/issues/CODEC-263?filter=allopenissues might have been fixed a couple of versions ago and can be closed. It's the only critical open issue in Jira. CODEC-249 and a few others could use some attention, but probably none of them are blockers. On Mon, Feb 5, 2024 at 9:27 AM Henri Biestro wrote: > > > [ +1 ] Release > > Build ok, tests ok, site looks good, report looks good (great coverage btw), > a japicmp report would be nice to have. > > Built using: > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) > Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.3", arch: "aarch64", family: "Mac" > On: > 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; > root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 arm64 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO-842] Deprecate more or undeprecate non-Charset methods
Except in Java 18 we do need it, for two independent reasons: 1. UTF-8 is still not the guaranteed, runtime character set that the various methods will use. JDKs can be configured to use a different default character set. Bugs from incorrect default character set will now be even harder to find since they won't be as obviously reproducible on all systems with a particular JDK. 2. Even if UTF-8 were the guaranteed, runtime character set that the various methods will use, that doesn't make UTF-8 correct. It depends on the input you're reading and the relevant specifications. Some of these use UTF-8. Some of these use ASCII or ISO 8859-1. A few use UTF-16 or something else. Just because the default character set is UTF-8, does not make any particular file or stream magically UTF-8. It is necessary to consider the context of the input source and choose the character encoding that is appropriate for that one source. We know from decades of experience that default character sets are unsafe and buggy. The safest approach is to provide higher level libraries that only accept byte streams as input and do character set conversion themselves according to spec. This is how JSON and XML parsers usually operate. But that's not always possible, and when it isn't, the most secure and bug-resistant API requires developers to think about their choice of character encoding and make their choice explicit. On Thu, Jan 25, 2024 at 5:37 PM Rob Tompkins wrote: > > I think we should remove the deprecations and add more explicit Javadocs that > spell out that there are oddities with the defaultCharset() depending upon > the operating system. Note this problem has been in existence since Java 1.4, > and we did nothing about it for a considerable amount of time. Plus in Java > 18 forward we simply don’t need it, as Gary said. > > Cheers, > -Rob > > > On Jan 24, 2024, at 1:45 PM, Gary D. Gregory wrote: > > > > Hi All, > > > > In the context of https://issues.apache.org/jira/browse/IO-842 and in light > > of UTF-8 being the default Charset for Java 18 and up on all platforms -- > > https://openjdk.org/jeps/400 --, we need to figure out whether to: > > > > - Deprecate all non-Charset methods in favor of their Charset versions, or > > - Un-deprecate existing deprecated non-Charset methods. > > > > See the ticket, please reply there or here as convenient. > > > > Gary > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Exec 1.4.0 based on RC1
d the 1.4.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.3): > > https://dist.apache.org/repos/dist/dev/commons/exec/1.4.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/exec/1.4.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-exec.git > --branch commons-exec-1.4.0-RC1 commons-exec-1.4.0-RC1 > cd commons-exec-1.4.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/exec/1.4.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > 6) Build the site for a multi-module project > > mvn site > mvn site:stage > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > Note that the project reports are created for each module. > Modules can be accessed using the 'Project Modules' link under > the 'Project Information' menu (see /modules.html). > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][NUMBERS] Method to convert unsigned long to BigInteger
On Sun, Dec 24, 2023 at 9:59 AM sebb wrote: > > Both Numbers and Statistics have implementations of > > BigInteger toUnsignedBigInteger(long treatedAsUnsigned) > Can you describe a use case for this? That might help decide where it belongs. I wouldn't be surprised if this is more suitable for lang than Math or Numbers. I'd also suggest a different method name. There's no such thing as an UnsignedBigInteger in Java. All BigIntegers are signed. Maybe something like toBigIntegerFromUnsigned -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?
On Thu, Dec 14, 2023 at 9:31 AM Arnout Engelen wrote: > > Examples of what I referred to as arbitrary code execution would be > unbounded deserialization of untrusted data (via techniques like those > described in the motivation for > https://docs.oracle.com/en/java/javase/17/core/serialization-filtering1.html > ) or (directly or indirectly) passing untrusted input to functions such as > "Runtime.exec()". I guess we can debate the word 'arbitrary', but it sounds > like you're saying *none* of the Apache Commons libraries should allow > triggering those? Passing untrusted input to Runtime.exec() or equivalent is definitely something we should fix (if we do that; I don't know that we do). I put that in the same category as bugs in native code commons itself ships. OTOH if we were to shell out to something like ImageMagick or ffmpeg and a malicious input file could trigger a security issue in the external tool, I wouldn't consider that our issue to filter or fix. In a worst case scenario, it would require us to replace a buggy and unmaintained dependency with something better. Object serialization I hope we don't use, but if we do it might be worth a look. This falls under the category of validating and not trusting any input you receive. The problem here is that a lot of developers don't do that when object serialization is used. They just assume the jDK does that for them and it very much does not. What I was thinking of for arbitrary code execution from pure Java code would be buffer overflow or rowhammer type attacks. That shouldn't be possible in Java, and when it is, it is almost by definition a JDK bug. There've been a few of these over the years. There've also been some zero days caused by flaws in the JDK libraries leading to arbitrary code execution. Again, these are JDK bugs. Mostly I want to avoid taking responsibility for things we don't own and can't fix: the JDK and native libraries from other projects. There's way too much noise in security reporting from random IT folk who've run some security scanner without really understanding what it's saying. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?
On Thu, Dec 14, 2023 at 6:09 AM Arnout Engelen wrote: > > Hello Commons developers, > > I'd like to discuss what our security ambitions are for components like > Commons Imaging, Compress, Codec and IO: > > Generally for Commons, we say that unless otherwise specified it is up to > the user of the library to make sure any input is either trusted or > correctly validated/sanitized (https://commons.apache.org/security.html). > > For these modules it might make sense to be a little more nuanced: > https://commons.apache.org/proper/commons-imaging/ already explicitly says > it intends to be "more secure against corrupt/malicious images", and while > the others don't seem to say it explicitly AFAICS in practice we consider > it OK to decompress/decode/... untrusted input at least to some degree. > > So what does that mean? > > * I'd say parsing/decompression/decoding should never allow malicious input > to trigger arbitrary code execution(?) Do any of these products include native libraries/C code? To the extent it's pure Java, arbitrary code execution indicates a bug in the JDK. Beyond that, I do not think Apache Commons (or anyone else) should expect *any* input to be correctly validated/sanitized. All products should be robust against arbitrary byte streams. Malformed input should be detected and an appropriate exception thrown. Excessive resource usage is a separate question since it can be triggered by valid input without escaping the VM protections. Proper input validation protects against some but not all resource exhaustion attacks. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons BCEL 6.8.0 based on RC1
OK, so bc means binary compatibility, not BCEL. That makes sense, though abbreviations are still confusing. Not urgent, but it would be worth adding build and release instructions to the repo some time. As is, I don't see any reference to the commons release plugin in the BCEL repo or docs. Release processes can be really painful to reverse engineer if everything is not written down in an obvious location and kept up to date. I've had to do that more than once in my career. :-( On Sun, Dec 3, 2023 at 5:18 PM Gary Gregory wrote: > > No, it should NOT be removed: It is used by the build/release plugins > to know which version to check for binary compatibility when the > default Maven goal runs the BC check and when the site report is > generated. > > Gary > > On Sun, Dec 3, 2023 at 12:13 PM Elliotte Rusty Harold > wrote: > > > > pom.xml has this strange variable: > > > > 6.7.0 > > > > Is that supposed to be the commons bcel version? If so, update it to > > 6.8.0. However, it doesn't seem to be used anywhere so perhaps just > > delete the line. > > > > > > On Sun, Dec 3, 2023 at 4:33 PM Gary Gregory wrote: > > > > > > We have fixed a few bugs and added some enhancements since Apache > > > Commons BCEL 6.7.0 was released, so I would like to release Apache > > > Commons BCEL 6.8.0. > > > > > > Apache Commons BCEL 6.8.0 RC1 is available for review here: > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1 (svn > > > revision 65804) > > > > > > The Git tag commons-bcel-6.8.0-RC1 commit for this RC is > > > cf6f7e710abf4eda2e0aa9aa914aa17878999583 which you can browse here: > > > > > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=cf6f7e710abf4eda2e0aa9aa914aa17878999583 > > > You may checkout this tag using: > > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > > > --branch commons-bcel-6.8.0-RC1 commons-bcel-6.8.0-RC1 > > > > > > Maven artifacts are here: > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1678/org/apache/bcel/bcel/6.8.0/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Sun Dec 03 11:17:12 EST 2023 > > > bcel-6.8.0-bin.tar.gz=955d66a5a34d25c90c71273467a2f876f3b3fb3437fc533f7a7583ea0390474817aefbb9a9b4190973011ad053e145c9c0bac42832f8198b562e693a25b2803f > > > bcel-6.8.0-bin.zip=04e5fe2830127add83108de8df61aab185e38a5117dddfa348533260b5d355da1fb0db56b0b5361e680308d2feea6a3b04acc99d6a93b9ad2dfdb943893cb583 > > > bcel-6.8.0-bom.json=1555e608b267a74adc10938377f8eb60f1b2fa477c1834582ded805530d3cf676ac14d6f1966bdd5d9ccef4cc9f2a32ff1ce6d9b6963fc1d288f8263585b639f > > > bcel-6.8.0-bom.xml=e1bb499766046147619dd1f1443089b043ee11bf09234c19f14b15261ae54e186c51bd2f7f9f622a71dac1d6a6712bef4c504bd21e975550bef6cfe886c607ba > > > bcel-6.8.0-javadoc.jar=5fdaa3d79e57a6fcff8e3dfd9295e4681d3f7b35ae6f248b6bee292e46f0f7cff6b80a88f198c6eed6a966be1e59d272e68f3d8dd39cee0b48ce8920e4ef7495 > > > bcel-6.8.0-sources.jar=a55973bc87409c525860709ff94055808cb46ce13f236f5a119e763ee4a024b9c0c3ac78c80c6e8489f6fc9c535aff8468f09a796889d5dc5c4f9dd593bb337e > > > bcel-6.8.0-src.tar.gz=fcec4920f841b9b22b7fe05190ed09a31e2edd32dbc9bc6217981af34fecab0725249bbaf0e5810e0c7ef8a347dbe07fa1dfc1a80a7b651368ad4ea852f54f6e > > > bcel-6.8.0-src.zip=4d7c00f9400b206db48823a77cb09bbb2b25074108e8980c84c701d6b73f77290cf3bed56e392d270c8e084d7c2306ac3fb9b4a4f7f1e6cb883b683f7b3d972e > > > bcel-6.8.0-test-sources.jar=8924279acde0fc8d101cc27b9e69b514b98a69793c990cadaae193da0fe5913630b99ebfd10568a3baa5e79bd4d93f8020202accf12a6a0e14ef07deb31736db > > > bcel-6.8.0-tests.jar=4d7715acb6d38d50f8a9e4cbef232190fd3d7efaf54ade772d677e129c89af69a528a1bff6dae6300058f2e1c1393acf18a554c85ac0a6f6d95f0aad4680426c > > > org.apache.bcel_bcel-6.8.0.spdx.json=dc47d97c197e3e0ce124b7f3a03e74552b6764e46195058d47daca19a597fb49469119115a58e7f3dc951cb851c031e60840e09d94632c4687332049dc305c10 > > > > > > I have tested this with: > > > > > > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site > > > deploy > > > > > > Using: > > > > > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > > > Maven home: /usr/local/Cellar/maven/3.9.6/libexec > > > Java version: 21.0.1, vendor: Homebrew, runtime: > > > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home > > > Default locale: en_US, platform encoding: UTF-8 > > > OS name: "mac os x", version: "1
Re: [VOTE] Release Apache Commons BCEL 6.8.0 based on RC1
t; This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > --branch commons-bcel-6.8.0-RC1 commons-bcel-6.8.0-RC1 > cd commons-bcel-6.8.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons BCEL 6.8.0 based on RC1
ns/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > --branch commons-bcel-6.8.0-RC1 commons-bcel-6.8.0-RC1 > cd commons-bcel-6.8.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Validator 1.8.0 based on RC1
The claimed security issue on apache commons appears to be broken. Possibly they're referring to this: https://news.apache.org/foundation/entry/apache_commons_statement_to_widespread which did not have a CVE On Sun, Dec 3, 2023 at 4:11 PM Piotr P. Karwasz wrote: > > Hi Elliotte, > > On Sun, 3 Dec 2023 at 14:13, Elliotte Rusty Harold wrote: > > > > https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-390 > > and https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-357 > > are both open dependency upgrades with security implications. If > > they've already been fixed, then please close the issues. > > > > If they haven't been fixed, I vote -1 until they are. Looking at head, > > I think VALIDATOR-357 has been fixed and should be closed, but > > VALIDATOR-390 is still open. > > Looking at the SBOM, the only dependencies (including transitive ones) are: > > * commons-beanutils 1.9.4, > * commons-digester 2.1, > * commons-logging 1.3.0, > * commons-collections 3.3.2. > > None of them have CVEs. > > Piotr > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Validator 1.8.0 based on RC1
That is annoying. Unless there are much more major breaking changes than FastHashMap planned for 2.0 in the near future, my inclination would be to kill it and jump straight to 2.0. But if you want to release 1.8 now, +0. On Sun, Dec 3, 2023 at 1:39 PM Gary Gregory wrote: > > Hello Elliotte, > > As Sebb's comments in VALIDATOR-390 point out, this issue can't be > fixed in the 1.x line, so your -1 would mean that there can't ever be > a 1.x release again. Or am I missing something? > > I am happy to switch master a 2.x line after 1.8.0 is out and break > binary compatibility at that point. > > Gary > > On Sun, Dec 3, 2023 at 8:13 AM Elliotte Rusty Harold > wrote: > > > > https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-390 > > and https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-357 > > are both open dependency upgrades with security implications. If > > they've already been fixed, then please close the issues. > > > > If they haven't been fixed, I vote -1 until they are. Looking at head, > > I think VALIDATOR-357 has been fixed and should be closed, but > > VALIDATOR-390 is still open. > > > > On Sat, Dec 2, 2023 at 3:26 PM Gary Gregory wrote: > > > > > > We have fixed a few bugs and added some enhancements since Apache > > > Commons Validator 1.7 was released, so I would like to release Apache > > > Commons Validator 1.8.0. > > > > > > Apache Commons Validator 1.8.0 RC1 is available for review here: > > > https://dist.apache.org/repos/dist/dev/commons/validator/1.8.0-RC1 > > > (svn revision 65799) > > > > > > The Git tag commons-validator-1.8.0-RC1 commit for this RC is > > > c4b1afc87797f7826b84ae7f024f3d8959781ddd which you can browse here: > > > > > > https://gitbox.apache.org/repos/asf?p=commons-validator.git;a=commit;h=c4b1afc87797f7826b84ae7f024f3d8959781ddd > > > You may checkout this tag using: > > > git clone https://gitbox.apache.org/repos/asf/commons-validator.git > > > --branch commons-validator-1.8.0-RC1 commons-validator-1.8.0-RC1 > > > > > > Maven artifacts are here: > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1677/commons-validator/commons-validator/1.8.0/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Sat Dec 02 10:19:35 EST 2023 > > > commons-validator-1.8.0-bin.tar.gz=32128ff8ec1d992a1654e1cab0451152e844dd3076c25c80122b331dd4d3546a60b0325476ae079b83a4b8d852dc8dd48fbde64f04d19e22013e99b95b98978e > > > commons-validator-1.8.0-bin.zip=436aa1b614144b35c644dc7f1725a72b16ba276ef2d66ceafb9964e2a2484cd3438f1d76bf82c8fdd9d6c4da47a34c8bad6897bad77528a7e1531f6c8eedf67a > > > commons-validator-1.8.0-bom.json=111c721363c61cd2a85a8f6b881b2d0fbaa0b2ac12401458e65e4e39ebc4a68ec339bf21d11d424ef0034ab0ad1239458011444a99843152b5a0c35f8922975a > > > commons-validator-1.8.0-bom.xml=1ecb419c19dce8d596cbe43e6c1690d8ce121fd1a9907b6e3a85a497517fedc0fa0ffc26acb3f7124672590a48b401e5a149c6d6fae3ee5067de8aabd7233ca7 > > > commons-validator-1.8.0-javadoc.jar=7a0b2ef23f2feb5f52269c47216f69137c62eec80a64bdd0e7ee7e413fd0d05c5c8b4c054f83a25dae8f0b3e3f4ef46663a05d9e67745196f870d4ce4a6e1b9e > > > commons-validator-1.8.0-sources.jar=fe6a7039615a53638df01b1100d25a6f38451b58cd5be88027e3bc0f86b40dfa440a8a466b7097054a1133c71089958e5f8a5bf6fad67e6c7bacc9210d04e97a > > > commons-validator-1.8.0-src.tar.gz=f0c2662e5db0bbc6ee9d05d5508caa02bf45b7c7ada92f4a97a867848f3d704b35552d47859a46567705194248e7b88cd8df8f082939012ab60b6aed446e36b2 > > > commons-validator-1.8.0-src.zip=530063f04d300c0322ef5c53960bd6dd2ea9879169efe64d28234ac9877b5638876e8ed020a16eb67198d528405d9656f6e94f08ffb7cdfaa0d9e916c77aa32f > > > commons-validator-1.8.0-test-sources.jar=f111abe654dbc2241d81dbf5b7742c33a1dd304ba1f2ffe902546b1e8b97a7d8940cffd1692e7787124fd08f54a235f92a19ade41fd88a136e5135ea10db4222 > > > commons-validator-1.8.0-tests.jar=bc5440747c3192574b75378fceb535ab7f988403d24fb1fb9ca74de30a5d7790fb9ed953bda3c727b5552778cdcf03e7e85500fadb3350a888c8adaf86da957d > > > commons-validator_commons-validator-1.8.0.spdx.json=36d397ce0e251258ec7a6a90f54a1d76585762e9ee680160b79979f73f4c31e506e8b6bc6e07186db83bc0e34a9996ccbefc069569f69753ef4fea2cdd40bb8b > > > > > > I have tested this with > > > > > > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site > > > deploy > > > > > > Using: > > > > > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > > > Maven home: /usr/local/Cellar/mave
Re: [VOTE] Release Apache Commons Validator 1.8.0 based on RC1
ds.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-validator.git > --branch commons-validator-1.8.0-RC1 commons-validator-1.8.0-RC1 > cd commons-validator-1.8.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/validator/1.8.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Is https://twitter.com/ApacheCommons still used?
Given the ongoing current and declining state of Twitter (to be more polite than I should be) I vote +1 on simply deleting the entire account. It's no longer a useful means of communicating with Java developers. I wouldn't be at all surprised if Space Karen decides to disable, deactivate, and/or recycle inactive and/or non-paid accounts in the near future. He's been leaning in that direction, is getting desperate for revenue, and has a history of impulsive, irrational decision making. Better to get out now before he does something even more problematic like auctioning off accounts to the highest bidding spammer. On Sat, Dec 2, 2023 at 8:53 PM sebb wrote: > > Indeed, well remembered! > > There is a file with the password. > > The intro to the file says: > > "Apache Commons has a twitter account that can be used > to post news about community activity, such as new > releases and so on." > > The last post was May 2019, and the one before Sep 2018, so it is not > exactly busy. > As such, I don't think it is worth promoting. > Whether it should be closed is another matter. > > Sebb > > On Sat, 2 Dec 2023 at 13:19, Bruno Kinoshita wrote: > > > > I think the password is in svn? In the pmc or private folder if I recall > > correctly. > > > > On Sat, 2 Dec 2023, 12:35 Gary Gregory, wrote: > > > > > I can't recall how we (PMC) access that account or if we even can, maybe > > > it's a marketing/PR account? > > > > > > Gary > > > > > > On Thu, Nov 30, 2023, 5:53 PM sebb wrote: > > > > > > > AFAICT https://twitter.com/ApacheCommons is no longer active, and > > > > links to it should be dropped. > > > > > > > > Note that it is not visible without a login. > > > > > > > > Sebb > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Suggestion for AbstractFileComparator
On Sat, Dec 2, 2023 at 12:01 AM Miguel Muñoz wrote: > > @Elliotte Rusty Harold, > I'd like to make two unrelated points. > 1. I wasn't suggesting the missingFilesFirst() or missingFilesLast() methods > as a solution to the issues raised in IO-813 LastModifiedFileComparator > should not throw exceptions, period. I just thought these methods would be > useful for cases where the users needs to sort file collections where some > files might not be valid anymore. This could easily arise in cases that are > unrelated to the issue in IO-813. Yes, I agree. I suspect this can also happen in a case where a file never existed. Java Path and File objects do not guarantee the existence of the file pointed to. It's just a name that might or might not correspond to a file. I do suspect that missingFilesFirst() or missingFilesLast() are overkill. We should pick one behavior and make it always work that way. > 2. As for your point about external conditions changing the code, I would > like to point out that working with a file system is hardly the only place > where developers will encounter this problem. Absolutely. Every case where this can happen is another place where a checked exception is needed. I/O is the most common example, but there are others. That said, threads are *not* such a case because they are completely internal to the program. Concurrency failures within a program are bugs that can and should be fixed by the devs who maintain that program. Having fixed such a bug, the exception should not be able to occur. Bug free concurrent programming is hard. Personally I'm bad at it. But it is possible. I/O error free programming in programs that access the file system is not possible. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Suggestion for AbstractFileComparator
I'm not sure we need two methods here, or even one. We simply need to detect a missing file and assign it a time like Integer.MIN_INT. Make the behavior as reproducible as reasonable for the case where the file doesn't exist and never existed. For cases where the last modified time changes or a file is deleted while a sort is executing, well that's why probably this class should be deprecated. No sorting algorithm is stable or correct when sorting by external conditions that change asynchronously outside the program's control while the sort executes. On Fri, Dec 1, 2023 at 4:50 AM Miguel Muñoz wrote: > > > > In my comments about issue IO-813 LastModifiedFileComparator should not > throw exceptions, period, I made a suggestion that I thought I'd repeat here. > I was thinking of adding these two methods to AbstractFileComparator. > > > > public static Comparator missingFilesFirst(Comparator > comparator) > > > public static Comparator missingFilesLast(Comparator > comparator) > > > These would work like Comparator.nullsFirst() and Comparator.nullsLast(). > They would allow users to work with collections of Files that might not point > to valid files, without having to worry about IOExceptions. > > > > I'm not sure if AbstractFileComparator is the best place to put it. It's not > a public class, but the methods would be available from any of the > subclasses. A better place might be in FileUtils, although that's in a > different package. > > > > What do you think? > > > > -- Miguel Muñoz > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons IO 2.15.1 based on RC1
+0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-io.git --branch > commons-io-2.15.1-RC1 commons-io-2.15.1-RC1 > cd commons-io-2.15.1-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/io/2.15.1-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VALIDATOR] - Release of newer version of validator without OWASP vulnerabilities
On Thu, Nov 23, 2023 at 3:10 PM sebb wrote: > > On Thu, 23 Nov 2023 at 13:05, Gary Gregory wrote: > > Generally a user can override the default version stated in the component pom. > Indeed this happens automatically in Maven if another jar declares a > dependency on a later version with the same Maven coordinates. Um, no, though this is a common misconception. Gradle, I think, works like that but Maven does not. In Maven the chosen dependency version is the first one encountered in a breadth-first search of the dependency tree. Older versions can and often are picked in preference to newer versions. It is possible for a client project to override transitive dependencies, but you need to be careful. Using a BOM is one of the easier ways to manage these problems: https://jlbp.dev/JLBP-15 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Bug in FileChannels.contentEquals?
Can you turn this into a PR against HEAD that adds a unit test that
fails? That would be fairly conclusive proof. It's better if you don't
send a fix, at least at first. That makes it easier to verify the bug.
On Mon, Nov 6, 2023 at 10:04 AM Stephan Markwalder
wrote:
>
> Hi,
>
> I think I have found a bug in the new FileChannels.contentEquals(...) in
> Commons IO 2.15.0 which then affects RandomAccessFiles.contentEquals(...),
> PathUtils.fileContentEquals(...), FileUtils.contentEquals(...), and maybe
> more methods. But before opening an issue in ASF JIRA, I would like to
> present my findings here.
>
> My current working hypothesis:
> If two files have the exact same size and the exact same content in the
> last 8192 bytes (value of IOUtils.DEFAULT_BUFFER_SIZE), then all of the
> above methods will return true, even if the content of the files is
> different before the last 8192 bytes.
>
> Here is some example code:
>
> // create two files with same size but different content
> // (3 different bytes followed by 8192 equal bytes)
> File file1 = new File("file1.txt");
> File file2 = new File("file2.txt");
>
> String sameContent = StringUtils.repeat("x", 8192);
>
> String content1 = "ABC" + sameContent;
> String content2 = "XYZ" + sameContent;
> FileUtils.writeStringToFile(file1, content1, StandardCharsets.US_ASCII);
> FileUtils.writeStringToFile(file2, content2, StandardCharsets.US_ASCII);
>
>
> // compare files
> boolean equals = FileUtils.contentEquals(file1, file2);
> System.out.println(equals);
>
>
> I would expect this to print "false" as the first 3 bytes are different,
> but the code prints "true". I tested with Eclipse Temurin 11.0.1, 17.0.7,
> and 21.0.1, all on MacOS.
>
> I'm not an expert on FileChannels, but I think the problem has something to
> do with the call to method FileChannel.read(ByteBuffer) in
> org.apache.commons.io.channels.FileChannels. Before the call to this
> method, the buffer is at position 0. After this call, the buffer is at
> position 8192. With a limit of 8192, this means that there are 0 remaining
> bytes to be compared in ByteBuffer.equals(...). Maybe there should be a
> call to ByteBuffer.rewind() or ByteBuffer.position(0) after the read so
> that the position is set back to 0 before comparing the content of the
> buffers? But as stated before, I'm not an expert on this topic. I'm also
> not sure whether my hypothesis is 100% accurate. But this has been my
> conclusion after some experiments.
>
> Best regards,
> Ste
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] parent uses commons.encoding=iso-8859-1; change to UTF-8?
https://survey.stackoverflow.co/2022#overview shows professional use of OS by developers has Windows below 50%, more than Mac or Linux but less than the combination of the two. The JetBrains 2021 survey also shows Mac + Linux > Windows: https://www.jetbrains.com/lp/devecosystem-2021/ (2022 doesn't seem to have asked that question) And if you've visited any US tech company or conference in the last ten years, you're familiar with the sea of MacBooks in the audience. Yes, there'll be a number of Thinkpads and those are as often as not running Linux. Maybe things are different outside the US, but in the US it's not even close. As a development platform, Windows is primarily used by programmers writing Windows apps, a large market but not one served by Java. It also has some traction in enterprises that have standardized on Windows across devs and non-devs alike. It's silly to stay on ISO-8859-1 for a very minor convenience to American and European Windows developers (an even smaller minority than Windows developers since not Windows machines outside Latin-alphabet languages already use other character sets.) UTF-8 is the standard, well-supported character encoding for everyone. On Fri, Oct 27, 2023 at 12:50 PM Gary Gregory wrote: > > On Fri, Oct 27, 2023 at 8:43 AM Elliotte Rusty Harold > wrote: > > > > +1 > > > > Using anything other than UTF-8 is a bug. > > > > There are more Java developers on Linux and Mac these days than > > Windows, nor will development tools on Windows have any problem with > > this. > > There is obviously no way to know that. > > Gary > > > > > On Fri, Oct 27, 2023 at 10:16 AM sebb wrote: > > > > > > As the subject says - it seems wrong to be using iso-8859-1 these days > > > as the default encoding. > > > > > > Thoughts? > > > > > > Sebb > > > > > > ----- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] parent uses commons.encoding=iso-8859-1; change to UTF-8?
+1 Using anything other than UTF-8 is a bug. There are more Java developers on Linux and Mac these days than Windows, nor will development tools on Windows have any problem with this. On Fri, Oct 27, 2023 at 10:16 AM sebb wrote: > > As the subject says - it seems wrong to be using iso-8859-1 these days > as the default encoding. > > Thoughts? > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Text 1.11.0 based on RC1
It's worth triaging the bug tracker sometime. At a quick glance I saw several other issues that are arguably security related, mostly around character escaping and unescaping. On Tue, Oct 24, 2023 at 11:43 AM Gary Gregory wrote: > > The issue is a year old with zero comments, I downgraded it to "Major". > > What's worse is that if it were a real security issue, it should have gone > through our security protocol and not a Jira (initially at least). > > Gary > > On Tue, Oct 24, 2023, 10:32 AM Elliotte Rusty Harold > wrote: > > > > > https://issues.apache.org/jira/projects/TEXT/issues/TEXT-220?filter=allopenissues > > is prirotized as a blocker. I haven't analyzed it in detail so I'm not > > sure, but it is security related. If it is a blocker it should be > > resolved before 1.11.0. If it is not a blocker, then the priority > > should be downgraded. > > > > On Tue, Oct 24, 2023 at 9:47 AM Gary Gregory > > wrote: > > > > > > We have fixed quite a few bugs and added some significant enhancements > > > since Apache Commons Text 1.10.0 was released, so I would like to > > > release Apache Commons Text 1.11.0. > > > > > > Apache Commons Text 1.11.0 RC1 is available for review here: > > > https://dist.apache.org/repos/dist/dev/commons/text/1.11.0-RC1 > > > (svn revision 64797) > > > > > > The Git tag commons-text-1.11.0-RC1 commit for this RC is > > > 6e2be58f54bb8e376fbb5188ad964cde2ff6f362 which you can browse here: > > > > > https://gitbox.apache.org/repos/asf?p=commons-text.git;a=commit;h=6e2be58f54bb8e376fbb5188ad964cde2ff6f362 > > > You may checkout this tag using: > > > git clone https://gitbox.apache.org/repos/asf/commons-text.git > > > --branch commons-text-1.11.0-RC1 commons-text-1.11.0-RC1 > > > > > > Maven artifacts are here: > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1670/org/apache/commons/commons-text/1.11.0/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Tue Oct 24 09:39:25 EDT 2023 > > > > > commons-text-1.11.0-bin.tar.gz=2e94877000dd270b69e2e8cbf49f258a90b4c628b6b6b0814e300a2f0e9c391f0816dceb0707e596ae3b7c9532f93e7a4917df47c77f44b3a810e14042ce5f3f > > > > > commons-text-1.11.0-bin.zip=f2480ffc6e9d1d678233830602da1c525814cfb8e951872dc4725d3a8e1957dcef8291309dc6ad20789003f04d61e21901eeb606d8f7a946e41c599dd0f35141 > > > > > commons-text-1.11.0-bom.json=1acd3a1a3b297f7460b8eb13d0e156644076186de422eaefd74af38e35885190c87e1ff4179222b6d96537a06069df2d03eb77b1bb24ccce8f854bb491e78334 > > > > > commons-text-1.11.0-bom.xml=e17bdf02c8704b62b5a3e27d500675704ffba3dd6d934b5f0877261feebac52037faa6f85eea3823422d5dcdcbc35314ec874c189c0cd20a82093a8598bfa7b9 > > > > > commons-text-1.11.0-javadoc.jar=63eb0a2c9004854d43ed3ea6e113af07aa2d11632af5beb17a3b1da8f65ef0cecb74e10ac2b496f67e4760cdeaf6925647d4b1fccd40dd6ce66dc076009c42d8 > > > > > commons-text-1.11.0-sources.jar=d937fe2eb28fa28a7b345338cc05b5101f3303baa501f8f6ad4a0efb604375b90997292bcccbdc994889415c3ea709b8b18497a04f83f050661db92a7f5ccaae > > > > > commons-text-1.11.0-src.tar.gz=3a97b58eae3e8a51fe46c3296021622bfe912869b2d9666c745f345d574bbc86307acfb39b329c6a544728b35d200487c6b752de1909a209692a2f00fb260460 > > > > > commons-text-1.11.0-src.zip=72d75261812df2f004aa680d6fbe5c71b77558f89ff03d117363f77811dfbda891c5f489dbae40132063ab1db1d5d30ca81da0674c79c817e9527b260d7a8560 > > > > > commons-text-1.11.0-test-sources.jar=44191a4135b572397131517eac9394564fef0129693110ced2e0d1c8585857b6eedebec8f653bb70f79d74e0334dcc7cc1f663a9101c262651e6e973251e875a > > > > > commons-text-1.11.0-tests.jar=e7d8c3d6e8c056fe793864d8cac4aa84e49789609fc7ea73270a3ba9829451300d4b6663641a013e3fc25d0ae97f57fc1258b303d89f6ed23c44116b22c0989c > > > > > org.apache.commons_commons-text-1.11.0.spdx.json=64b008e082a13db858015e8680183a83d4a29be73dba66b5eb49b6ea77e11b676f1f8b997ab4fce49f0778423b97612516139679af1cb552b3adf65f296cccb7 > > > > > > I have tested this with: > > > > > > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site > > deploy > > > > > > Using: > > > > > > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > > > Maven home: /usr/local/Cellar/maven/3.9.5/libexec > > > Java version: 21, vendor: Homebrew, runtime: > > > /usr/local/Cellar/openjdk/21/libexec/openjdk.jdk/Contents/Home > > > Default locale: en_US, platform encoding: UTF-8 > > > OS name: "mac os x&quo
Re: [VOTE] Release Apache Commons Text 1.11.0 based on RC1
OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-text.git > --branch commons-text-1.11.0-RC1 commons-text-1.11.0-RC1 > cd commons-text-1.11.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/text/1.11.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons IO 2.15.0 based on RC1
t... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-io.git --branch > commons-io-2.15.0-RC1 commons-io-2.15.0-RC1 > cd commons-io-2.15.0-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/io/2.15.0-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot
It's possible the chi square test is miscalculated. Perhaps some stats expert can check that. It's also possible the chi square test isn't the right one to use here. Again, consult a stats expert. It's also very possible that the randomness is not nearly as random as it's supposed to be. That's incredibly common, and that might be noticeable given the very short three-letter character set [a, b, c] being picked from. On Fri, Oct 20, 2023 at 1:31 PM Gary D. Gregory wrote: > > Despite the failure comment: > > RandomStringUtilsTest.testRandomStringUtilsHomog:474 test homogeneity -- will > fail about 1 in 1000 times ==> expected: but was: > > This test fails a LOT more than once every 1000 times, based on how many > GitHub builds I need to restart every week. > > What can be done to make this test more resilient? > > TY! > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Dbutil] Java 8 -> 11
There's no rule that you have to change the package name and Maven coordinates with a major version bump. As long as the API is compatible, it's OK to keep those. But breaking compatibility with Java 8 is a pretty big step forward. The goal is to allow people to produce and accept bug fixes in libraries without being forced to upgrade to a JDK version they might not actually need, or even be actively prohibited from using. JDK 8 --> 9+ is a huge shift, much bigger than 7 --> 8, that breaks a lot of projects in unexpected ways. On Sun, Oct 15, 2023 at 2:32 PM Gary Gregory wrote: > > A major version bump is rather heavy handed when no one is asking for a > "real" 2.0 with breaking changes. A major bump would imply a package name > and Maven coordinate change. At least that's what we have done before for > major version changes. We've also done major version changes without those > types of changes BUT it would be nice to be consistent. For example, to > update to Java 11 for Commons Lang without a package name change would mean > calling it 4.0 while the package stays as lang3, confusing. > > Gary > > On Sun, Oct 15, 2023, 9:17 AM Elliotte Rusty Harold > wrote: > > > Not a library I use so I don't have a horse in the race. However, I do > > recommend making this a major version bump to 2.0 so as not to close > > off the possibility of critical fixes for folks still on older JDKs. > > > > On Sun, Oct 15, 2023 at 8:42 AM Gary Gregory > > wrote: > > > > > > We've recently released DBUtils after a long period of inactivity. Java > > 21 > > > is also out. I plan on raising the floor for this component to Java 11 > > and > > > GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any > > > Java 21 issues yet. > > > > > > Gary > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > ----- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Dbutil] Java 8 -> 11
Not a library I use so I don't have a horse in the race. However, I do recommend making this a major version bump to 2.0 so as not to close off the possibility of critical fixes for folks still on older JDKs. On Sun, Oct 15, 2023 at 8:42 AM Gary Gregory wrote: > > We've recently released DBUtils after a long period of inactivity. Java 21 > is also out. I plan on raising the floor for this component to Java 11 and > GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any > Java 21 issues yet. > > Gary -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [EMAIL] Fluent interface
Personal opinion: it probably wasn't intentional, but please don't do that. It doesn't help anyone and is needless churn. Fluent methods are not better than non-fluent ones, and are in fact less semantic and harder to debug. They prioritize saving code writing over code maintainability. Not just personal opinion: The API MUST not be changed in an incompatible way. Changing the return type of an overridable method is an incompatible change that is forbidden. Return types of non-overridable methods (final, private, or static) might be able to be changed, but still shouldn;t be. On Fri, Sep 29, 2023 at 7:13 AM Filip Strajnar wrote: > > Greetings, > > > I've noticed that some methods on the org.apache.commons.mail.Email > class provide fluent interface (examples include setCc, addBcc, > addReplyTo), and some do not (to name a few: setAuthentication, > setSmtpPort, setMailSession). Is this intentional, or am I allowed to > submit a PR that would change all relevant void methods so that they > would return an Email object instead? > > > Sincerely, > > Filip Strajnar > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
+1 LGTM On Sat, Sep 9, 2023 at 11:57 AM Gary Gregory wrote: > > Maven coordinates changed because the package name changed per our > conventions. > > Gary > > On Sat, Sep 9, 2023, 7:53 AM Elliotte Rusty Harold > wrote: > > > To be clear, not just the Maven coordinates but also the package names > > have changed (to fileupload2) in this release? If so, this should be > > fine. I just want to double check because this step is often missed, > > with real much client pain resulting. > > > > On Fri, Sep 8, 2023 at 10:19 PM sebb wrote: > > > > > > FTR: > > > > > > Note that this release uses different Maven coordinates: > > > > > > org.apache.commons > > > commons-fileupload2 > > > 2.0.0-M2-SNAPSHOT > > > > > > The previous release (1.5) used: > > > > > > commons-fileupload > > > commons-fileupload > > > 1.5 > > > > > > On Fri, 21 Jul 2023 at 17:28, > > wrote: > > > > > > > > Hello Gary, > > > > > > > > does that include Milestone releases as well or not? > > > > > > > > Regards > > > > Jeremias > > > > > > > > -Original Message- > > > > From: Gary Gregory > > > > Sent: Friday, 21 July 2023 17:08 > > > > To: Commons Developers List > > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > > > [**EXTERNAL E-MAIL**] > > > > > > > > All releases go to MC. > > > > > > > > Gary > > > > > > > > On Fri, Jul 21, 2023, 10:47 > > > > > > wrote: > > > > > > > > > Hello Gary, > > > > > > > > > > are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven > > > > > Central as well? > > > > > That would make the testing easier. > > > > > > > > > > Regards > > > > > Jeremias > > > > > > > > > > -Original Message- > > > > > From: Gary Gregory > > > > > Sent: Friday, 21 July 2023 15:43 > > > > > To: Commons Developers List > > > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > > > > > [**EXTERNAL E-MAIL**] > > > > > > > > > > This is a milestone release because we might not have the gotten the > > > > > API just right for a major release. This gives up the opportunity to > > > > > receive feedback and adjust the API for what will be 2.0.0. All lot > > of > > > > > folks will not try a snapshot build, which then leaves us in the > > dark. > > > > > > > > > > WRT to the missing data, I'll adjust that but it won't show up on the > > > > > site until the next version is published. > > > > > > > > > > HTH, > > > > > Gary > > > > > > > > > > > > > > > On Fri, Jul 21, 2023, 08:53 Christoph Grüninger > > > > > wrote: > > > > > > > > > > > Hi Gary! > > > > > > > > > > > > Thank you for this release and thanks to all the diligent > > contributors! > > > > > > Having a new release with new features, cleaned-up interfaces, and > > > > > > updated dependencies is much appreciated! > > > > > > I also learned from the recent discussion whether FileUpload is > > > > > > still a good idea [1]. > > > > > > > > > > > > > The Apache Commons FileUpload Parent team is pleased to announce > > > > > > the > release of Apache Commons FileUpload Parent 2.0.0-M1. > > > > > > > > > > > > Why is the release called "-M1" and not plain 2.0.0? > > > > > > > > > > > > When I follow > > > > > > https://commons.apache.org/proper/commons-fileupload/ > > > > > > the top release entry in the Downloading section for version 2.0.0 > > > > > > lacks the release date. > > > > > > > > > > > > Kind regards, > > > > > > Christoph > > > > > > > > > > > > > > > > > > [1] > > https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9 > > > > > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > > > > have received this e-mail by mistake, and delete it. We thank you for > > > > > your support. > > > > > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > have received this e-mail by mistake, and delete it. We thank you for your > > support. > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
To be clear, not just the Maven coordinates but also the package names have changed (to fileupload2) in this release? If so, this should be fine. I just want to double check because this step is often missed, with real much client pain resulting. On Fri, Sep 8, 2023 at 10:19 PM sebb wrote: > > FTR: > > Note that this release uses different Maven coordinates: > > org.apache.commons > commons-fileupload2 > 2.0.0-M2-SNAPSHOT > > The previous release (1.5) used: > > commons-fileupload > commons-fileupload > 1.5 > > On Fri, 21 Jul 2023 at 17:28, > wrote: > > > > Hello Gary, > > > > does that include Milestone releases as well or not? > > > > Regards > > Jeremias > > > > -Original Message- > > From: Gary Gregory > > Sent: Friday, 21 July 2023 17:08 > > To: Commons Developers List > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > [**EXTERNAL E-MAIL**] > > > > All releases go to MC. > > > > Gary > > > > On Fri, Jul 21, 2023, 10:47 > > wrote: > > > > > Hello Gary, > > > > > > are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven > > > Central as well? > > > That would make the testing easier. > > > > > > Regards > > > Jeremias > > > > > > -Original Message- > > > From: Gary Gregory > > > Sent: Friday, 21 July 2023 15:43 > > > To: Commons Developers List > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > [**EXTERNAL E-MAIL**] > > > > > > This is a milestone release because we might not have the gotten the > > > API just right for a major release. This gives up the opportunity to > > > receive feedback and adjust the API for what will be 2.0.0. All lot of > > > folks will not try a snapshot build, which then leaves us in the dark. > > > > > > WRT to the missing data, I'll adjust that but it won't show up on the > > > site until the next version is published. > > > > > > HTH, > > > Gary > > > > > > > > > On Fri, Jul 21, 2023, 08:53 Christoph Grüninger > > > wrote: > > > > > > > Hi Gary! > > > > > > > > Thank you for this release and thanks to all the diligent contributors! > > > > Having a new release with new features, cleaned-up interfaces, and > > > > updated dependencies is much appreciated! > > > > I also learned from the recent discussion whether FileUpload is > > > > still a good idea [1]. > > > > > > > > > The Apache Commons FileUpload Parent team is pleased to announce > > > > the > release of Apache Commons FileUpload Parent 2.0.0-M1. > > > > > > > > Why is the release called "-M1" and not plain 2.0.0? > > > > > > > > When I follow > > > > https://commons.apache.org/proper/commons-fileupload/ > > > > the top release entry in the Downloading section for version 2.0.0 > > > > lacks the release date. > > > > > > > > Kind regards, > > > > Christoph > > > > > > > > > > > > [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9 > > > > > > > > -------- > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > > have received this e-mail by mistake, and delete it. We thank you for > > > your support. > > > > > > > > > > If you are not the addressee, please inform us immediately that you have > > received this e-mail by mistake, and delete it. We thank you for your > > support. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Imaging] Drop Serializable
On Thu, Aug 31, 2023 at 3:26 PM Gary Gregory wrote: > > Why? > I assumed it was post 1.0. If that's not the case, then sure, whatever. API compatibility is not promised yet. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Imaging] Drop Serializable
This should be a major version bump. On Thu, Aug 31, 2023 at 1:26 PM Gary Gregory wrote: > > Hi All, > > I propose we drop implementating Serializable and avoid any and all > possible security issues in this area. > > Gary -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] - Contribution Support
Java 8 is **not** EOL. It is fully supported by multiple vendors including Oracle, which has committed to supporting it indefinitely. Some JDK 8 downloads from Oracle are no longer available without a support contract. That's all. Java 8 is in common use at many organizations and in many projects. I no longer have access to industry wide metrics about JDK versions, but based on what I could see a year ago, I'm pretty confident JDK 8 will be with us through the end of the decade, and likely longer. When a bug or security issue is fixed in Apache Commons, clients should be able to quickly upgrade to a new release of the library without updating their JDK. This is critical for maintaining secure infrastructure. Maintenance and legacy code isn't as sexy as refactoring working code to use the latest super-happy-lambda-fun-time-absolutely-no-bugs-we-promise feature from Java 38 EA 17, but it's much more important for producing robust software that does the job it needs to do. On Thu, Aug 24, 2023 at 11:23 AM Gary Gregory wrote: > > IMO, requiring Java 11 is acceptable, Java 21 is around the corner and Java > 8 is EOL anyway. > > Gary > > On Thu, Aug 24, 2023, 6:34 AM Elliotte Rusty Harold > wrote: > > > On Thu, Aug 24, 2023 at 8:28 AM Buddhi De Silva > > wrote: > > > > > > HI Team, > > > > > > Also, some tickets contain the patch files > > > provided by the community and some of them seem to be accepted by the > > > Apache CSV team but ticket status is Open and unresolved. > > > In this case, before I dig into some issues for possible fixes, I would > > > like to know whether all open issues in the CSV Jira board are still > > valid > > > and planned to be integrated in the upcoming releases if we have possible > > > PRs. > > > > Almost certainly not. Just because some random dev files a feature > > request does not imply that anyone else, much less project > > maintainers, consider it a good idea. A lot of these should be triaged > > but I'm not sure who has permissions to do that. > > > > If you're looking for something to work on, try to get consensus on > > the mailing list that a feature is a good idea before commencing work. > > You could probably work on obvious bugs safely too. That is, anything > > where anyone who looks at it would immediately say, yeah, it';s not > > doing what the docs say it does. > > > > I would stay far away from any issue that suggests changing the API > > incompatibly or requiring JDK 11+. That's a non-starter. > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] - Contribution Support
On Thu, Aug 24, 2023 at 8:28 AM Buddhi De Silva wrote: > > HI Team, > > Also, some tickets contain the patch files > provided by the community and some of them seem to be accepted by the > Apache CSV team but ticket status is Open and unresolved. > In this case, before I dig into some issues for possible fixes, I would > like to know whether all open issues in the CSV Jira board are still valid > and planned to be integrated in the upcoming releases if we have possible > PRs. Almost certainly not. Just because some random dev files a feature request does not imply that anyone else, much less project maintainers, consider it a good idea. A lot of these should be triaged but I'm not sure who has permissions to do that. If you're looking for something to work on, try to get consensus on the mailing list that a feature is a good idea before commencing work. You could probably work on obvious bugs safely too. That is, anything where anyone who looks at it would immediately say, yeah, it';s not doing what the docs say it does. I would stay far away from any issue that suggests changing the API incompatibly or requiring JDK 11+. That's a non-starter. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-lang] Util function in NumberUtils to count significant figures in a numeric string
Are there any existing projects that have this functionality now? E.g. if there's some physics project, some ML project, and some DNA project that have all had to reinvent this particular wheel, that's both good evidence that we need it and something to inform us of what a useful API might look like here. If, on the other hand, this isn't commonly useful, then we might not want to carry the ongoing maintenance burden for these methods. On Thu, Aug 10, 2023 at 2:55 PM Daniel Watson wrote: > > I brought this up in commons-math and it was determined that that probably > wasn't a good place for it, as that lib focuses on computational functions. > It was also mentioned that commons-numbers was not a great place for the > static util method either. > > Essentially the need for this relates to scientific measurements. > Measurements are often reported with implied precision and uncertainty > (e.g. 0.0015 has 2 significant figures, 1.10 has 3, etc). Currently there > are no Number classes that retain or respect this information. There are > widely accepted conventions for how to retain and adjust both precision and > uncertainty during mathematical operations. But the first step is simply > knowing what those two values are. I propose a util method (already > written) in NumberUtils that can do this. The conventions are widely > documented but would be spelled out very specifically in the javadoc. > Although NumberUtils mainly focuses on pure math transformation, it does > also include some parsing, so this doesn't seem to be *completely* out of > scope. > > Is NumberUtils a possible home for this? > > On a separate, but related note, I honestly think this sort of math > actually deserves a full blown java Number implementation (similar to > BigFraction and Complex classes in commons- numbers). Possibly called > BigMeasurement? Which can interact with other Number implementations as > well as other BigMeasurements and retain/report the correct uncertainty and > precision throughout the computation. I haven't ironed that out - but a > necessary intermediate step is just being able to get the sigfig count. > > Dan -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Codec] clearing input byte array vs not
I still think the input byte array should not be cleared, period. Clearing is a separate operation that should be performed by the caller. On Sat, Aug 12, 2023 at 12:52 PM Gary Gregory wrote: > > Coming back around to this now that Mark fixed the mailing list noise. > > Git master now documents the existing clearing behavior as suggested by > Mark in https://lists.apache.org/thread/cyrpgsqx4lnjlsf3frqwfo5pvbmpcycr > > Next, is how to document or change Crypt.crypt(byte[], String): The method > clears the input byte array for all input types _except_ when calling > UnixCrypt [1]. > > I could: > (1) Document the inconsistency (right now, I left it unsaid) > (2) Make UnixCrypt.crypt() clear its input password for consistency. > > WDYT? > > Gary > > On Wed, Aug 9, 2023, 6:24 PM Gary Gregory wrote: > > > FYI, I created https://issues.apache.org/jira/browse/INFRA-24876 > > > > Gary > > > > On Wed, Aug 9, 2023, 6:16 PM GitLab wrote: > > > >> Unfortunately, your email message to GitLab could not be processed. > >> > >> We couldn't figure out what the email is for. Please create your issue or > >> comment through the web interface. > >> > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
On Wed, Aug 9, 2023 at 11:36 PM Daniel Watson wrote: > > Meant to add... > > The reason I would favor exceptions is that the underlying implementation > can be easily customized. If the user needs to allow non alphanumeric > characters there is a boolean flag in the underlying abstract class > (AbstractConfigurableCase) that will simply turn that validation off. This is another point, but customizability is a bug, not a feature. I don't want to guess what the method might be doing based on what flag was set where. I want camel case to mean one thing and one thing only. Ditto snake case, pascal case, and any other formats. Possibly there's a reason to add additional subclasses, but the CamelCase/SnakeCase/KebabCase classes should not emit different strings depending on how they're configured. The public API should be a pure function, not an object. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
On Wed, Aug 9, 2023 at 11:50 PM Daniel Watson wrote: > my-component-1 > > Is a valid kebab cased string, with tokens my,component,1 > > However this cannot be formatted in camel case or Pascal case, because they > are delimited by alpha characters. > Not necessarily so. The last implementation I worked on (Python) in fact did handle this case. This is why it's important to really lock down the precise definition of these formats before worrying about which exceptions to throw when. I know from experience that it is possible to write an algorithm for snake case <--> camel case conversions that converts any string with no exceptions because I've done it (not in open source, unfortunately), but that might depend on the definition of the format. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
Checked exception is almost certainly wrong. But I'm not sure we need any exception at all here. I don't think these methods need any exceptions at all aside from NullPointerException for null inputs. Otherwise, every string should have a deterministic representation in camel case, pascal case, etc. Is there any external documentation of these forms we could reference? On Wed, Aug 9, 2023 at 10:21 PM Hasan Diwan wrote: > > [content inline] > > On Wed, 9 Aug 2023 at 15:08, Elliotte Rusty Harold > wrote: > > > What happens when a token contains an unpermitted character? > > > > Three possibilities: > 1. null -- favoured by Square's HTTP implementation. > 2. a checked Exception --preferred by the JDK. > 3. an unchecked Exception -- leveraged by various commons projects, like > commons-math's interpolate method. -- H > -- > OpenPGP: https://hasan.d8u.us/openpgp.asc > If you wish to request my time, please do so using > *bit.ly/hd1AppointmentRequest > <http://bit.ly/hd1AppointmentRequest>*. > Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest > <http://bit.ly/hd1AppointmentRequest>*. > > <https://sks-keyservers.net/pks/lookup?op=get=0xFEBAD7FFD041BBA1>Sent > from my mobile device > Envoye de mon portable -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
What happens when a token contains an unpermitted character? On Wed, Aug 9, 2023 at 8:30 PM Daniel Watson wrote: > > Here's my stab at a spec. Wanted to clarify some parts of the Case > interface first before jumping into the implementations. Wondering what a > good package name for this stuff is, given that "case" is a reserved word? > > Case (interface) > The Case interface defines two methods: > * String format(Iterable tokens) > The format method accepts an Iterable of String tokens and returns a single > String formatted according to the implementation. The format method is > intended to handle transforming between cases, thus tokens passed to the > format() method need not be properly formatted for the given Case instance, > though they must still respect any reserve character restrictions. > * List parse(String string) > The parse method accepts a single string and returns a List of string > tokens that abide by the Case implementation. > Note: format() and parse() methods must be fully reciprocal. ie. On a > single Case instance, when calling parse() with a valid string, and passing > the resulting tokens into format(), a matching string should be returned. > > DelimitedCase (base class for kebab and snake) > Defines a Case where all tokens are separated by a single character > delimiter. The delimiter is considered a reserved character and is not > allowed to appear within tokens when formatting. No further restrictions > are placed on token contents by this base implementation. Tokens can > contain any valid Java String character. DelimitedCases can support > zero-length tokens, which can occur if there are no characters between two > instances of the delimiter or if the parsed string begins or ends with the > delimiter. > Note: Other Case implementations may not support zero-length tokens, and > attempts to call format(...) with empty tokens may fail. > > KebabCase > Extends DelimitedCase and initializes the delimiter as the hyphen '-' > character. This case allows only alphanumeric characters within tokens. > > SnakeCase > Extends DelimitedCase and initializes the delimiter as the underscore '_' > character. This case allows only alphanumeric characters within tokens. > > PascalCase > Defines a Case where tokens begin with an uppercase alpha character. All > subsequent token characters must be lowercase alpha or numeric characters. > Whenever an uppercase alpha character is encountered, the previous token is > considered complete and a new token begins, with the uppercase character > being the first character of the new token. PascalCase does not allow > zero-length tokens when formatting, as it would violate the reciprocal > contract of format() and parse(). > > CamelCase > Extends PascalCase and sets one additional restriction - that the first > character of the first token (ie the first character of the full string) > must be a lowercase alpha character (rather than the uppercase requirement > of PascalCase). All other restrictions of PascalCase apply. > > > On Tue, Aug 8, 2023 at 8:55 PM Daniel Watson wrote: > > > Kebab case is extremely common for web identifiers, eg html element ids, > > classes, attributes, etc. > > > > In regards to PascalCase, i agree that most people won't understand the > > reasoning behind the name, but it is nevertheless a widely accepted term > > for that case style. If an alternative is deemed necessary then > > "ProperCase" might work - since that is also how English proper nouns are > > cased. Understanding that name just depends on your knowledge of English > > grammar. > > > > A spec can definitely be written for the 4 provided concrete > > implementations. And... I may eat these words but... the spec should not be > > all that complex. I will take a stab at it. > > > > Thanks for the feedback! > > Any other thoughts or comments are welcome! > > > > Dan > > > > > > On Tue, Aug 8, 2023, 7:45 PM Elliotte Rusty Harold > > wrote: > > > >> This is a good idea and seems like useful functionality. In order to > >> accept it into commons, it needs solid documentation and excellent > >> test coverage. I've worked on code like this in another language (not > >> Java) and the production bugs were bad. E.g. what happens when a > >> string contains numbers as well as letters? > >> > >> I'd like to see a full spec that unambiguously defines how every > >> Unicode string is converted into camel/snake/kebab case. The spec > >> should be independent of the code. That's not easy to write but it's > >> essential. > >> > >> I don't want
Re: [Codec] clearing input byte array vs not
This makes sense to me. The existing behavior seems surprising and incorrect. Is there a reason for it? On Wed, Aug 9, 2023 at 6:53 PM Gary Gregory wrote: > > Hi all, > > Any thoughts on https://github.com/apache/commons-codec/pull/197 > > Gary -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
This is a good idea and seems like useful functionality. In order to
accept it into commons, it needs solid documentation and excellent
test coverage. I've worked on code like this in another language (not
Java) and the production bugs were bad. E.g. what happens when a
string contains numbers as well as letters?
I'd like to see a full spec that unambiguously defines how every
Unicode string is converted into camel/snake/kebab case. The spec
should be independent of the code. That's not easy to write but it's
essential.
I don't want any loose/strict modes. It should all be strict according to spec.
I've never heard of kebab cases before. Is that a common name? I'd
also like to rename Pascal case. How many programmers under 40 have
even heard of Pascal, much less are familiar with its case
conventions?
Long story short - a PR is premature until there's an agreed upon spec.
On Tue, Aug 8, 2023 at 8:04 PM Daniel Watson wrote:
>
> I have a bit of code that adds the ability to parse and format strings into
> various case patterns. Wanted to check if it's of worth and in-scope for
> commons-text...
>
> Its a bit broader than the existing CaseUtils.toCamelCase(...) method.
> Rather than simply formatting tokens into the case, this API adds the
> additional goal of being able to transform one case to another. e.g.
>
> SnakeCase.format(PascalCase.parse("MyPascalString")); // returns
> My_Pascal_String
> CamelCase.format(SnakeCase.parse("my_snake_string")); // returns
> mySnakeString
> KebabCase.format(CamelCase.parse("myCamelString")); // returns
> my-Camel-String
> //Note that kebab and snake do not alter the alphabetic case of the tokens,
> as they are essentially case agnostic joining, according to this
> implementation. Though this can be overridden by end users.
>
> The API has one core interface: Case, which has format and parse methods.
> There is a single abstract implementation of it - AbstractConfigurableCase
> - which is a configuration driven way to create a case pattern. It has
> enough options to accommodate the 4 popular cases, and thus the subclasses
> just have to configure these options rather than implement them directly.
> Any further extensions can override or extend the api as necessary.
>
> There are five core concrete implementations:
>
> PascalCase
> CamelCase (extends PascalCase)
> DelimitedCase
> KebabCase (extends DelimitedCase)
> SnakeCase (extends DelimitedCase)
>
> Each has a static INSTANCE field to avoid redundant instantiation.
>
> Some of my reasoning / concerns...
>
> * I considered bundling all of this logic into static methods, similar to
> CaseUtils, but that prevents the user from truly customizing or extending
> the code for odd cases. This approach is, in my opinion, far easier to
> understand, extend, and debug.
> * I believe the parsing side should potentially have a loose / strict mode,
> in that the logic can ignore non-critical rules on the parsing side. e.g.
> the command CamelCase.parse("MyString") should work, even though the input
> is not strictly camel case. Strict parsing would ensure (if possible) that
> the input abides by all elements of the format.
> * I'm still unsure about how best to handle reserved characters when
> translating. e.g. How should
> KebabCase.format(PascalCase.parse("MyPascal-String")) handle the hyphen?
> Should the kebab case strip the reserved character from the token values?
>
> Long story short - is this worth pursuing in the form of a pull request for
> review? Or is it out of scope for commons-text?
>
> Dan
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [FileUpload] Major version 2
Absolutely not Java 17. There are really big companies still on Java 11, and I have no idea how many smaller ones. There are many still on Java 8. Unless you actually **need** something from Java 11+ I wouldn't bother. On Fri, Jul 21, 2023 at 10:18 AM Gary Gregory wrote: > > Now that 2.0.0-M1 is out the door, let's talk about Java platform > requirements. > > I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17. > > If you are going to ask why, see my reply in the [pool] thread > (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk) > > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Another source compatibility break in 2.x
On Thu, Jul 20, 2023 at 8:27 PM Phil Steitz wrote: > > We have a minor source compat break still in 2.x > > The change to have BaseGenericObjectPool implement Autocloseable forced > addition of an abstract close method. Technically, that could break > subclass implementations that don't implement close. I see three options > here. Maybe someone else has a better idea. > > 0) Ignore the problem. Unlikely to actually impact anyone. > 1) Add a default implementation that > a) throws UnsupportedOperationException > b) No-Ops > c) does > 2) Add Implements Autocloseable to the subclasses (GOP, GKOP, ...) instead > 3) Revert the change for 2.x > Weak vote for 1b. That maintains source compatibility and the API you want and doesn't seem likely to cause problems in any situation I can think of. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
On Wed, Jul 19, 2023 at 11:38 AM Gilles Sadowski wrote: > I think that the page one would look for is this one: >https://commons.apache.org/proper/commons-math/dependency-info.html It's fine to put it there, but even if it's correct it's still too hard to find. The only way to get to that page is scroll about two thirds of the way down a sidebar and click one of the four links that mention "dependencies" that seems as likely to bring you to a list of commons-math's own dependencies rather than how to add this project as a dependency. I'm a Maven comitter who's spent way more time in the depths of Maven Project website generation than 99.9% of Java programmers and I still couldn't find this the first time I looked for it. That's de facto evidence that this information is not easy to find. This coordinates belong right up front on https://commons.apache.org/proper/commons-math/index.html I am tempted to see about changing the title of that page in the sidebar from "Dependency Information" to "Maven Coordinates". That would help a little and it's likely commons-math is hardly the only project that has this issue. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
On Wed, Jul 19, 2023 at 9:53 AM Gilles Sadowski wrote: > > org.apache.commons.math4 and org.apache.commons.math3 > > > > Although it's not easy to find, > > What do you mean? > Is it something we can fix here? > Probably. I did a google search and hunted around on the web pages at https://commons.apache.org/proper/commons-math/ Nowhere did I find a clear statement that "To import commons-math to a project use the coordinates org.apache.commons:commons-math3:3.6.1" or anything like that. I just took another look and I see something for 4.0 at https://commons.apache.org/proper/commons-math/summary.html but that's not the first place someone would look, and that's only for the parent project. Not should the main website be for an unreleased version. I'd put this on both Overview pages and probably the Developer's Guide page at https://commons.apache.org/proper/commons-math/ -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Commons Math 4 and Commons Math 3 have different java packages: org.apache.commons.math4 and org.apache.commons.math3 Although it's not easy to find, it does look like the Maven coordinates have changed as well. so it's effectively a completely new release of a new project that can coexist with the older project in a classpath. That shouldn't cause any dependency problems. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Ok, don't do that unless it's new code in new packages. Otherwise you're creating a dependency hell for existing clients. It is extremely developer hostile. Pretty much all of https://jlbp.dev/ applies but especially JLBP-5: Do not include a class in more than one classpath entry JLBP-6: Rename artifacts and packages together Debugging the problems this will cause is difficult and painful, even for someone well-versed in Maven dependency management. On Wed, Jul 19, 2023 at 11:37 AM Dimitrios Efthymiou wrote: > > no. I mean creating maven modules inside commons-math, like > the existing ones: > commons-math-neuralnet > commons-math-transform > > On Wed, 19 Jul 2023 at 12:29, Elliotte Rusty Harold > wrote: > > > Could you be precise about what you mean by "modularisation"? It's a > > very overloaded term. Do you mean Java 9 modules as defined by the > > JPMS? > > > > On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou > > wrote: > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > modularisation of all 14 packages commons-math-legacy has? I think that > > > some of them are easy to modularise like optimisation, special and filter > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] advertising unchecked exceptions
On Tue, Jul 18, 2023 at 10:54 PM Phil Steitz wrote: > > I am going through now and comparing diffs of 2.11.1 and head of 2.x to > make sure that me and sed did not do anything wrong and I am seeing a bunch > of things like this: > > -void addObject() throws Exception, IllegalStateException, > -UnsupportedOperationException; > +void addObject() throws Exception; > > Where the new version is the 2.x code. I am inclined to leave as is, maybe > adding comments in some places indicating when the unchecked exceptions > might be thrown. Any objections? > That sounds good. This is generally best practice for runtime exceptions. Don't include them in throws clauses but do include @throws Javadoc for each one. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Could you be precise about what you mean by "modularisation"? It's a very overloaded term. Do you mean Java 9 modules as defined by the JPMS? On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou wrote: > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > modularisation of all 14 packages commons-math-legacy has? I think that > some of them are easy to modularise like optimisation, special and filter -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou wrote: > > hello. I never said to redesign APIs. I only said that we can > move math algorithms from non-math projects, to the math projects > No, don't do that. Method signatures must not change. Class names must not change. Package names must not change. Group and artifact IDs must not change. Split packages are not allowed. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Move NO algorithms from ANY projects to math libraries
There are a lot of proposals floating recently to churn the API. I'm going to move a direct no on all of this. Mild improvements in consistency in no way justify any API breakage or even deprecation. Every method and class that currently exists in any commons library should continue to exist there with the same signature indefinitely. Compatibility is far more important than consistency. Do NOT redesign or rethink the APIs at this late date. Too much depends on them. New methods, classes, and packages, and projects can be added where appropriate. Internals can be improved as possible. But what's there today stays there, absent the very rare case where critical bugs or security issues require breaking an API. However, that's extremely uncommon. No API will ever be perfect or free from hindsight. But the cost of change is too high to justify breaking commons libraries. Stare decisis is as valuable a principle in API design as in law. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069
On Mon, Jul 3, 2023 at 12:20 AM Gary Gregory wrote:
>
> Hi Elliotte:
>
> Might you be looking at some old code in the PR?
>
Just looking at what was posted in the email thread. It's a weird
corner case not everyone thinks of.
> The current code is:
>
> /**
> * Checks if a throwable represents a checked exception
> *
> * @param throwable
> *The throwable to check.
> * @return True if the given Throwable is a checked exception.
> * @since 3.13.0
> */
> public static boolean isChecked(final Throwable throwable) {
> return throwable != null && !(throwable instanceof Error) &&
> !(throwable instanceof RuntimeException);
> }
This also looks wrong. This might work:
public static boolean isChecked(final Throwable throwable) {
return throwable != null && throwable instanceof Exception &&
!(throwable instanceof RuntimeException);
}
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069
On Sun, Jul 2, 2023 at 8:53 PM Alex Herbert wrote:
> public static boolean isUnchecked(final Throwable throwable) {
> return (throwable instanceof Error) || (throwable instanceof
> RuntimeException);
> }
Not quite. It's also possible for someone to define a subclass of
Throwable directly that is neither an Exception nor an Error.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
On Thu, Jun 29, 2023 at 11:43 AM Gilles Sadowski wrote: > I think I can understand your rationale: Something that can be > corrected at runtime should be signalled by a checked exception. > Right? No, not at all. Recoverability is **not** the distinction between checked and unchecked exceptions. Checked exceptions should arise from conditions outside the program itself, like a malformed file or a broken network connection. Runtime exceptions should arise from issues inside the program, like invoking a method on a variable whose value is null, or passing -28 to a method that will only accept positive numbers. > However I don't understand why you now add "Error" to the mix... Because recoverability is the distinction between Exceptions and Errors. Most of the time exceptions, checked and unchecked, can be recovered from. Errors usually can't be. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
On Thu, Jun 29, 2023 at 10:48 AM Gilles Sadowski wrote: > The situation is recoverable from the caller's POV, by performing a > *new* call, with a correct argument. We certainly don't need a special > kind of exception[1] to handle this situation. What's wrong with catching > a "RuntimeException" if you know how to try again? > The problem isn't with catching a RuntimeException. The problem is with *not* catching the RuntimeException because the compiler doesn't make you do this, and the programmer forgets. Checked exceptions are for cases that SHOULD have an error handler, and simply makes the omission of one an easy-to-fix compile time error instead of a hard-to-fix runtime error. If the code in question shouldn't have an error handler, typically because the code in question is buggy and should be fixed so that the exception is never thrown in the first place, then a runtime exception is appropriate. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
On Thu, Jun 29, 2023 at 10:10 AM Gilles Sadowski wrote: > > Le jeu. 29 juin 2023 à 15:22, Elliotte Rusty Harold > a écrit : > > > > On Thu, Jun 29, 2023 at 9:07 AM Gilles Sadowski > > wrote: > > > > > > Hello. > > > > > > Le jeu. 29 juin 2023 à 14:44, Gary Gregory a > > > écrit : > > > > > I agree with the second part assuming the *current* Java > > > best practices, not because of old APIs that are here to stay > > > only because of infinite backwards compatibility, and not > > > because they are deemed perfect. > > > > > > Best practices on this haven't changed since Java 1.0 (Possibly Java > > 1.0 alpha 3 if I recall versions correctly). > > > > Checked exceptions: all errors arising from external input to the program. > > Runtime exceptions: program bugs > > A pile of arguments (tally is largely against *any* use of checked > exceptions): > > https://ohadshai.medium.com/its-almost-2020-and-yet-checked-exceptions-are-still-a-thing-bfaa24c8997e tldr; he's wrong. More details: https://www.youtube.com/watch?v=rJ-Ihh7RNao=419s > > > > I don't know which applies here, but 99% of the time this is all you > > need to consider to figure out whether a checked or runtime exception > > is called for. There are indeed a lot of old broken APIs that don't > > follow these simple rules, > > The rules which you stated are far from simple because "external" > depends on the POV (more below). > > Commons components like [RNG], [Geometry], [Numbers], [Math] > only throw unchecked exceptions. Libraries you link to are not external to the program. Runtime exceptions might be appropriate here. > The only rule that ever made sense to me is from J. Bloch's "Effective > Java": > ---CUT--- > Use checked exceptions for recoverable conditions and runtime > exceptions for programming errors > ---CUT--- This is about the only thing in that book where I disagree with Bloch. At the very least this is not said as well as it needs to be. Recoverable vs unrecoverable distinguishes Errors from Exceptions, not runtime exceptions from checked exceptions. You can interpret that sentence to mean "bugs are not recoverable short of fixing the code" in which case sure, runtime exceptions are not recoverable. > For example, *all* precondition failures are, from the POV of the > called function, a programming error (akin to NPE or IAE). This is correct. NPEs and IAEs are programming errors. > Whether the root cause is an "internal" or "external" error is irrelevant > at the point where the issue is detected (where the runtime exception > just conveys that "the call was inappropriate"). It's not about the root cause. It's about the immediate cause. Passing null or another illegal argument to a method that isn't ready to receive it is a programming error, i.e. a bug, and therefore these are properly runtime exceptions. > > and it's never fun when a system goes down > > in production because some random JSON yahoo thought checked > > exceptions were "icky". > > A bug of the application, by the "absent-minded" developer mentioned > in the previous mail. > In Java, nothing prevents the throwing of a runtime > exception; the developer *always* must enclose "foreign" code in a > "try/catch" block, to protect the system. There is no need for checked > exceptions just to remember this (really) simple rule. Had the JSON library properly used checked exceptions, the programmer would not have been able to compile code that contained this mistake. The reason we have strong static typing, unit tests, and checked exceptions is that programmers are imperfect humans. Let the machines do the work that machines are good at, including checking whether errors are properly handled. > > Lately I've been working in Python, and error handling practice in > > this community is abominable. The lack of checked exceptions is a > > large reason why Python code is expected to be unreliable and Python > > programs routinely dump stack. > > I've heard that it's rather the result of "script"-oriented design, or lack > thereof... :-) There's more than one reason. :-) -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1
On Thu, Jun 29, 2023 at 9:07 AM Gilles Sadowski wrote: > > Hello. > > Le jeu. 29 juin 2023 à 14:44, Gary Gregory a écrit : > I agree with the second part assuming the *current* Java > best practices, not because of old APIs that are here to stay > only because of infinite backwards compatibility, and not > because they are deemed perfect. Best practices on this haven't changed since Java 1.0 (Possibly Java 1.0 alpha 3 if I recall versions correctly). Checked exceptions: all errors arising from external input to the program. Runtime exceptions: program bugs I don't know which applies here, but 99% of the time this is all you need to consider to figure out whether a checked or runtime exception is called for. There are indeed a lot of old broken APIs that don't follow these simple rules, and it's never fun when a system goes down in production because some random JSON yahoo thought checked exceptions were "icky". Lately I've been working in Python, and error handling practice in this community is abominable. The lack of checked exceptions is a large reason why Python code is expected to be unreliable and Python programs routinely dump stack. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes
On Thu, Jun 29, 2023 at 8:12 AM Gary Gregory wrote:
>
> On Thu, Jun 29, 2023 at 7:20 AM Elliotte Rusty Harold
> wrote:
> I'm not sure what you are proposing. Adding a new filter to IO that
> behaves like Ant? Adding a new filter to IO that behaves like Python?
> Are Ant and Python expressions _exactly_ the same_? Even if they are
> the same today, what happens when Python decides to change?
I'm mostly interested in Maven, whose syntax is at least exactly the
same as Ant's used to be when the code was copied years ago. It's
probably still the same today.
More generally, I think Python glob is evidence that developers want
and need something like this. That is, it's useful to have file globs
with ?, *, and ** but not full regexps. It seems that would be a
generally useful thing for Commons IO.
Except now I have just discovered (via Wikipedia) that Java 7+ in fact
already has PathMatcher.getMatcher("glob") and maybe that will do all
of this? Need to explore further.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes
On Mon, Jun 19, 2023 at 8:17 PM Gary Gregory wrote: > I like the general idea of adding configurable include and exclude features. > > I am uncertain about baking in the Ant-specific pattern formats in > Commons IO. Allowing the include and exclude feature to be provided > through some interfaces and/or lambdas would be fine, which would then > enable Ant to pass its pattern syntax processor. > FYI in an unrelated project I happened to notice that as of version 3.5 this is also the format supported by the Python glob function. It's not just ant and Maven. This is a fairly common thing to want. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes
On Tue, Jun 27, 2023 at 9:22 AM Gary Gregory wrote: > > I think that we are close to what Ant needs > with org.apache.commons.io.filefilter.WildcardFileFilter. Perhaps Ant > should just implement its own "AntWildcardFileFilter" as a copy or subclass > of WildcardFileFilter. > > Or, are you thinking that WildcardFileFilter should have a new toggle "star > star matches Ant's behavior"? > "Toggles" aren't really OOP-native. I'd prefer a completely new class even if much of the implementation is shared with WildcardFileFilter. I'm still working out in my head what I think this should look like, but a single class that implements a well-understood, well-documented file filter syntax and otherwise can be plugged into existing classes like Files.walkFileTree — i.e. the Strategy pattern — is probably about as simple as we can get. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Possible addition of getFiles/getFileNames and Ant includes/excludes
On Mon, Jun 19, 2023 at 8:17 PM Gary Gregory wrote: > > I like the general idea of adding configurable include and exclude features. > > I am uncertain about baking in the Ant-specific pattern formats in > Commons IO. Allowing the include and exclude feature to be provided > through some interfaces and/or lambdas would be fine, which would then > enable Ant to pass its pattern syntax processor. > That seems like indirections on top of indirections. PathFilter and FileFilter already offer sufficient indirection here. Adding more interfaces or lambdas on top of the existing interfaces feels excessive. On further investigation, org.apache.commons.io.filefilter.WildcardFileFilter already covers most of what this needs. That is, it handles ? and * globs in paths. The piece it's missing is a double asterisk ** to select everything below a directory. According to ant docs, "To make things a bit more flexible, we add one extra feature, which makes it possible to match multiple directory levels. This can be used to match a complete directory tree, or a file anywhere in the directory tree. To do this, ** must be used as the name of a directory. When ** is used as the name of a directory in the pattern, it matches zero or more directories. For example: /test/** matches all files/directories under /test/, such as /test/x.java, or /test/foo/bar/xyz.html, but not /xyz.xml." -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[io] Possible addition of getFiles/getFileNames and Ant includes/excludes
I'm working on a longterm project to remove a lot of duplicate code and assorted dependencies from Apache Maven by migrating many of our utilities to Apache Commons equivalents or near-equivalents. In particular I'd much prefer to use Apache Commons IO to handle a lot of file system related tasks rather than reinventing and maintaining those wheels ourselves. There's some common history here going back 20+ years where code has been copied and pasted from one project to the next, and then maintained and evolved with different levels of care in different projects. I've found JDK or Commons IO replacements for almost everything I/O related in our old utility library. I'm now down to the last group of methods. These are several variants of getFiles/getFileNames that return a list of the files inside a base directory as relative paths from the base, either as String or File objects. There's nothing exactly like this in commons IO. I think AccumulatorPathVisitor along with Files.walkFileTree covers a lot of what it does. It's not a drop-in 1:1 replacement, but it should suffice for most uses. The final missing piece is that the legacy getFiles/getFileNames methods also support Ant includes and excludes lists: @param includes the Ant includes pattern, comma separated @param excludes the Ant excludes pattern, comma separated (I think this code originated in ant a couple of decades ago.) I think I can make this work with AccumulatorPathVisitor using a file filter that accepts ant includes and excludes lists. My question is twofold: 1. Would the commons IO project be open to accepting a contribution of a file filter that is based on Ant includes and excludes patterns? No actual ant code, just the pattern syntax described here: https://ant.apache.org/manual/dirtasks.html#patterns 2. Would the commons IO project be open to accepting something closer to the existing getFiles/getFileNames methods from maven-shared-util? likely based on the file filter from #1 https://javadoc.io/doc/org.apache.maven.shared/maven-shared-utils/latest/org/apache/maven/shared/utils/io/FileUtils.html#getFileAndDirectoryNames(java.io.File,java.lang.String,java.lang.String,boolean,boolean,boolean,boolean) The current methods are a bit of a mess with an IMHO excessive number of options and overloads, so it wouldn't be a pure copy of the API, but it would be a single method that could do something like List files = Files.getFiles(directory) List fileNames = Files.getFileNames(directory) to return a List of files contained within a directory. I think the implementation would be based on AccumulatorPathVisitor and Files.walkFileTree rather than copying the current code that dates back to something like Java 1.2. Thoughts? Is this something the commons IO project would be willing to own? If so, I can file an issue and begin working on a PR. Thanks for the consideration. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Commons-logging status
Hello, I wanted to check on the status of commons-logging. It hasn't been updated since 2014 and it doesn't seem to be much used these days. However, it does show up in multiple projects' dependency trees, and there is activity in the github repo. Is a new release anticipated? If so, any ideas what version number it will have and what minimum version of Java it will require? Thanks. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
