Re: [lang] ObjectUtils enhancement - consumer with non-null value
Gary,
LANG-1634 [1] and PR 684 [2] opened for review.
Rob - yes exactly. I have found myself writing that utility method
multiple times, and almost all of those projects had commons-lang as a
dependency, so figured this would be a good place to have this
reusable piece of code.
Bindul
[1] https://issues.apache.org/jira/browse/LANG-1634
[2] https://github.com/apache/commons-lang/pull/684
On Mon, Dec 28, 2020 at 12:20 PM Rob Spoor wrote:
>
> applyIfNonNull looks to be a version of Optional without the Optional
> object. The following is the same as suggested but with an additional
> Optional object:
>
> Optional.ofNullable(valueX).ifPresent(bean::setValue);
> Optional.ofNullable(valueX).ifPresent(v -> someObject.compute(v,
> "bar"));
>
> Or, combined:
>
> Optional.ofNullable(valueX).ifPresent(v -> {
> bean.setValue(v);
> someObject.compute(v, "bar");
> });
>
> The new method is shorter and saves the Optional object, so it may have
> some value. I think I've even written the applyIfNonNull method myself
> several times.
>
>
> On 28/12/2020 15:39, Gary Gregory wrote:
> > Hi Bindul,
> >
> > Let's see what this would look like with a PR :-)
> >
> > Gary
> >
> > On Mon, Dec 28, 2020, 01:23 Bindul Bhowmik wrote:
> >
> >> Hi,
> >>
> >> I would like to propose an enhancement to the ObjectUtils class in lang:
> >>
> >> Background: I have seen multiple places in code where we have to check
> >> if a value is null before using it in a setter or other method, like:
> >>
> >> if (valueX != null) {
> >> bean.setValue(valueX);
> >> someObject.compute(valueX, "bar");
> >> }
> >>
> >> I was wondering if there is interest to add a method like the
> >> following in ObjectUtils:
> >>
> >> public static void applyIfNonNull(final Consumer consumer,
> >> final T object)
> >> public static void applyFirstNonNull(final Consumer
> >> consumer, final T... objects)
> >>
> >> With this the two statements above could be applied as:
> >>
> >> ObjectUtils.applyIfNonNull(bean::setValue, valueX);
> >> ObjectUtils.appyIfNonNull(v -> someObject.compute(v, "bar"), valueX);
> >>
> >> Of course, the benefit of this increases with more such null checks we
> >> need in the code that can be replaced by single statements.
> >>
> >> I am happy to open a JIRA and GH pull request if there is interest in
> >> this minor enhancement.
> >>
> >> Bindul
> >>
> >> -
> >> 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
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[lang] ObjectUtils enhancement - consumer with non-null value
Hi,
I would like to propose an enhancement to the ObjectUtils class in lang:
Background: I have seen multiple places in code where we have to check
if a value is null before using it in a setter or other method, like:
if (valueX != null) {
bean.setValue(valueX);
someObject.compute(valueX, "bar");
}
I was wondering if there is interest to add a method like the
following in ObjectUtils:
public static void applyIfNonNull(final Consumer consumer,
final T object)
public static void applyFirstNonNull(final Consumer
consumer, final T... objects)
With this the two statements above could be applied as:
ObjectUtils.applyIfNonNull(bean::setValue, valueX);
ObjectUtils.appyIfNonNull(v -> someObject.compute(v, "bar"), valueX);
Of course, the benefit of this increases with more such null checks we
need in the code that can be replaced by single statements.
I am happy to open a JIRA and GH pull request if there is interest in
this minor enhancement.
Bindul
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Releasing 1.1.0 with Mac64 support
Hi Gary, (Please ignore if it has been discussed already) On Mon, Jul 27, 2020 at 12:07 PM Gary Gregory wrote: > > Hi All, > > Thanks to Geoffrey Blake's help setting up a Docker Ubuntu Trusty (14.04) > environment, I am working toward creating an RC for 1.1.0, but in order to > get Mac64 support we are quite sure I need to build that binary on a Mac, > which I do not own or have simple access to. > > Is there an acceptable workflow for me, the Release Manager, to procure > said binary from another person? Does that person need to be on the Commons > PMC, a Commons Committer, an Apache Commons, an Apache Member, or can it be > Anyone? > > There is an obvious trust issue here since I would not be the one building > the Mac64 binary but would be delivering it through our dist area and Maven > Central. commons-crypto is built on OSX on travis. So, a thought on getting the binaries out of that: If you had a place for travis to upload the artifacts: you could fork the repo, alter the .travis.yml to add a deployment step to upload the built OSX binaries to your location. I think this gets you, the release manager, a known good binary. You can add whatever 'on' conditions for the deploy to only upload binaries from the tag, etc. I am suggesting forking the repo, so the altered .travis.yml is not in the release source tag and the secrets to upload the binary are only in your github/travis org. > > Yes, I know that in theory, Apache only delivers source code and that our > binary distributions are only a convenience, so there might be nothing to > talk about, still, I want to make sure to check on expectations and > processes. > > Gary Bindul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Todo utility class
On Thu, Mar 15, 2018 at 4:05 PM, Gilles wrote: > Hi. > > On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote: >> >> I have often thought about creating a utility class that allows me to >> write >> skeletal code that still compiles but will remind me to go back and finish >> it. This is a weird meta area of programming, but here are some basic >> usage >> examples: >> >> Foo foo = Todo.todo(); //returns null >> Bar bar = Todo.todo(THROWING_EXCEPTION); //throws NotImplementedException >> Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and >> prints a message to System.err >> >> I would also think it a good (if odd) idea to make the whole class >> deprecated so that its use is flagged in tools, etc. >> >> Does the community think this code would be suited to the commons-lang >> component? > > > Perhaps "Commons Testing". > IIUC, such calls are not meant to appear in released code. I would recommend against commons testing. i would assume that component would be a dependency with a test scope in most projects, making it impossible to use it in the main code. Regards, Bindul > > Regards, > Gilles > >> >> Matt > > > > - > 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
Re: [RNG] Travis build fails with JDK 9
On Fri, Feb 9, 2018 at 2:14 PM, Gilles wrote: > On Thu, 8 Feb 2018 22:44:32 -0700, Bindul Bhowmik wrote: >> >> On Thu, Feb 8, 2018 at 9:01 AM, Gilles >> wrote: >>> >>> Hi. >>> >>> Build succeeds with JDK 7 and 8 but not with JDK9: >>> https://travis-ci.org/apache/commons-rng/jobs/337207823 >>> >>> Did someone encounter this problem? >> >> >> Taking a guess here: looking at line 3521 of the log [1], it looks >> like the symptom described in the surefire FAQ [2] about corrupted >> streamps. I don't know RNG code to comment, > > > It's unikely to be caused by RNG; from the "dump", it looks > like error messages generated by "jacoco", that in turn > interfere with the "surefire" plugin's expectations. > >> but maybe a quick check >> will be to try the build without forking (forkCount=0) > > > The build proceeds correctly with this setting. > Thanks. Glad I could help. However, I might have a better solution for you. I had a little time today, so checked out the code and tried the build; and as you correctly noted above it is jacoco that is causing pain. So, I tried updating the version of jacoco and the build works fine with jacoco 0.8.0 (updated 0.8.0) and without the forkCount configuration setting (basically default forkcount). Looking at Jacoco's release notes [4], looks like you need 0.8.0 for proper Java 9 support. > >> or using a >> snapshot of surefire 2.21.0 [3], which seems to have a few more Java 9 >> goodies. > > > I don't know how to retrieve a snapshot version of the > plugin. You can add the Apache snapshot repository [5] to your maven settings. As of writing this email 2.21.0-SNAPSHOT from 08 FEB is available there. You could also clone the surefire repository and build locally. But, either way, now you don't need to do it, updating JaCoCo should fix your build issues. Regards, Bindul [4] http://www.jacoco.org/jacoco/trunk/doc/changes.html [5] https://repository.apache.org/content/repositories/snapshots/ > > Regards, > Gilles > >> >> Bindul >> >> [1] https://travis-ci.org/apache/commons-rng/jobs/337207823#L3521 >> [2] >> >> >> http://maven.apache.org/surefire/maven-surefire-plugin/faq.html#corruptedstream >> [3] https://issues.apache.org/jira/projects/SUREFIRE/versions/12341630 >> >>> >>> Regards, >>> Gilles >>> >>> P.S. Build also fails locally (on Debian "stretch") with the >>> same error: >>> ---CUT--- >>> [...] >>> [ERROR] Error occurred in starting fork, check output in log >>> [ERROR] Process Exit Code: 134 >>> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The >>> forked VM terminated without properly saying goodbye. VM crash or >>> System.exit called? >>> [...] >>> ---CUT--- > > > > - > 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
Re: [RNG] Travis build fails with JDK 9
On Thu, Feb 8, 2018 at 9:01 AM, Gilles wrote: > Hi. > > Build succeeds with JDK 7 and 8 but not with JDK9: > https://travis-ci.org/apache/commons-rng/jobs/337207823 > > Did someone encounter this problem? Taking a guess here: looking at line 3521 of the log [1], it looks like the symptom described in the surefire FAQ [2] about corrupted streamps. I don't know RNG code to comment, but maybe a quick check will be to try the build without forking (forkCount=0) or using a snapshot of surefire 2.21.0 [3], which seems to have a few more Java 9 goodies. Bindul [1] https://travis-ci.org/apache/commons-rng/jobs/337207823#L3521 [2] http://maven.apache.org/surefire/maven-surefire-plugin/faq.html#corruptedstream [3] https://issues.apache.org/jira/projects/SUREFIRE/versions/12341630 > > Regards, > Gilles > > P.S. Build also fails locally (on Debian "stretch") with the > same error: > ---CUT--- > [...] > [ERROR] Error occurred in starting fork, check output in log > [ERROR] Process Exit Code: 134 > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The > forked VM terminated without properly saying goodbye. VM crash or > System.exit called? > [...] > ---CUT--- > > > - > 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
Re: [configuration] Notifications from commons-configuration GitHub mirror
On Sat, Jan 20, 2018 at 8:39 AM, Oliver Heger wrote: > > > Am 15.01.2018 um 18:04 schrieb Oliver Heger: >> Hi, >> >> Am 14.01.2018 um 00:33 schrieb Bindul Bhowmik: >>> Hello, >>> >>> It seems notifications from the commons-configuration GitHub mirror >>> are not setup to go to any commons mailing list. >>> >>> I opened a trivial pull request - #10 [1], but I don't see any emails >>> on any commons lists for this pull request [2] (well this thread will >>> show up on the search after it makes it to the archives :-)) >>> >>> Similar searches for other commons components show emails, like [3] and [4]. >> >> thank you for the pull request - I will have a look. >> >> Regarding missing mail notifications, I am not sure whether this could >> be caused by the fact that [configuration] still uses SVN and is not yet >> properly setup for a Github integration. Switching to Git is somewhere >> on my Todo list, but I have not yet found the time to do this. >> >> Oliver > > The patch has been applied in revision r1821751. I also republished the > web site, so that it shows now the correct version number. > > Thanks again for the patch. Thank you for merging the patch, somehow I did not notice the patch. I have closed the PR now. Bindul > > Oliver > >> >>> >>> Bindul >>> >>> [1] https://github.com/apache/commons-configuration/pull/10 >>> [2] >>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-configuration/pull/ >>> >>> [3] >>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-io/pull/ >>> [4] >>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-lang/pull/ >>> >>> - >>> 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 >> > > - > 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
Re: [compress] Planning 1.16 Release - With Source Incompatible Change
Stefan, On Sun, Jan 28, 2018 at 4:08 AM, Stefan Bodewig wrote: > Hi all > > https://issues.apache.org/jira/projects/COMPRESS/versions/12341948 has a > nice set of new features and fixes and I'd like to cut a release > candidate the coming days. Not sure if this has anything to do with the recent JIRA upgrade or not, but the link above is not accessible for non logged in Jira users. I think versions could be viewed without logging into Jira before the upgrade. > > One thing I may want to do is to extend the "preserveLeadingSlashes" > attribute of TarArchiveEntry to also preserve the drive letter on > Windows - this issue Torsten raised. > > Apart from that does anybody see anything that should go into the > release? > > I've created the site for the current state of master, it can be found > at https://stefan.samaflost.de/staging/commons-compress-1.16/ > > If you look at > https://stefan.samaflost.de/staging/commons-compress-1.16/japicmp.html > there is a change flagged as source incompatible. The abstract class > LZ77Compressor$Block has a new abstract method. IMHO this is acceptable > as the Block class really only serves an internal purpose and it has > always been expected that all subclasses of it are part of Commons > Compress. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > Bindul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[configuration] Notifications from commons-configuration GitHub mirror
Hello, It seems notifications from the commons-configuration GitHub mirror are not setup to go to any commons mailing list. I opened a trivial pull request - #10 [1], but I don't see any emails on any commons lists for this pull request [2] (well this thread will show up on the search after it makes it to the archives :-)) Similar searches for other commons components show emails, like [3] and [4]. Bindul [1] https://github.com/apache/commons-configuration/pull/10 [2] https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-configuration/pull/ [3] https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-io/pull/ [4] https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-lang/pull/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-compress git commit: [COMPRESS-392] Add Brotli decoder based on the Google Brotli library.
On Tue, May 2, 2017 at 1:22 PM, wrote:
> Repository: commons-compress
> Updated Branches:
> refs/heads/master 932d4f899 -> a793612b9
>
>
> [COMPRESS-392] Add Brotli decoder based on the Google Brotli library.
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-compress/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/commons-compress/commit/a793612b
> Tree: http://git-wip-us.apache.org/repos/asf/commons-compress/tree/a793612b
> Diff: http://git-wip-us.apache.org/repos/asf/commons-compress/diff/a793612b
>
> Branch: refs/heads/master
> Commit: a793612b9e09795feb253aab9a738bd1f7280700
> Parents: 932d4f8
> Author: Philippe Mouawad
> Authored: Tue May 2 12:22:04 2017 -0700
> Committer: Gary Gregory
> Committed: Tue May 2 12:22:04 2017 -0700
>
> --
> pom.xml | 7 ++
> src/changes/changes.xml | 3 +++
> .../compressors/CompressorStreamFactory.java| 25 +++-
> 3 files changed, 34 insertions(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-compress/blob/a793612b/pom.xml
> --
> diff --git a/pom.xml b/pom.xml
> index 9745d1b..4cc629a 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,6 +68,12 @@ jar, tar, zip, dump, 7z, arj.
>test
>
>
> + org.brotli
> + dec
> + 0.1.1
> + true
> +
> +
>org.tukaani
>xz
>1.6
> @@ -245,6 +251,7 @@ jar, tar, zip, dump, 7z, arj.
>
>
>
> org.tukaani.xz;resolution:=optional
> +
> org.brotli.dec;resolution:=optional
>
>
>
>
> http://git-wip-us.apache.org/repos/asf/commons-compress/blob/a793612b/src/changes/changes.xml
> --
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index d40a1a8..acd06f0 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -103,6 +103,9 @@ The type attribute can be add,update,fix,remove.
> Internal location pointer in ZipFile could get incremented
> even if nothing had been read.
>
> + due-to="Philippe Mouawad">
> +Add Brotli decoder based on the Google Brotli library.
> +
>
> description="Release 1.13 - API compatible to 1.12 but requires
> Java 7 at runtime.">
>
> http://git-wip-us.apache.org/repos/asf/commons-compress/blob/a793612b/src/main/java/org/apache/commons/compress/compressors/CompressorStreamFactory.java
> --
> diff --git
> a/src/main/java/org/apache/commons/compress/compressors/CompressorStreamFactory.java
>
> b/src/main/java/org/apache/commons/compress/compressors/CompressorStreamFactory.java
> index b12fc1a..29cf0cf 100644
> ---
> a/src/main/java/org/apache/commons/compress/compressors/CompressorStreamFactory.java
> +++
> b/src/main/java/org/apache/commons/compress/compressors/CompressorStreamFactory.java
> @@ -31,6 +31,8 @@ import java.util.Set;
> import java.util.SortedMap;
> import java.util.TreeMap;
>
> +import
> org.apache.commons.compress.compressors.brotli.BrotliCompressorInputStream;
> +import org.apache.commons.compress.compressors.brotli.BrotliUtils;
> import
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream;
> import
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorOutputStream;
> import
> org.apache.commons.compress.compressors.deflate.DeflateCompressorInputStream;
> @@ -93,6 +95,16 @@ public class CompressorStreamFactory implements
> CompressorStreamProvider {
>
> private static final CompressorStreamFactory SINGLETON = new
> CompressorStreamFactory();
>
> +
> +
> +/**
> + * Constant (value {@value}) used to identify the BROTLI compression
> + * algorithm.
> + *
> + * @since 1.1
> + */
> +public static final String BROTLI = "br";
Gary,
Shouldn't the @since value be 1.14 here?
Bindul
> +
> /**
> * Constant (value {@value}) used to identify the BZIP2 compression
> * algorithm.
> @@ -263,6 +275,10 @@ public class CompressorStreamFactory implements
> CompressorStreamProvider {
> private static ArrayList
> findCompressorStreamProviders() {
> return Lists.newArrayList(serviceLoaderIterator());
> }
> +
> +public static String getBrotli() {
> +return BROTLI;
> +}
>
> public static String getBzip2() {
> return BZIP2;
> @@ -524,6 +540,13 @@ public class CompressorStreamFactory implements
> CompressorStreamProvider {
> if (BZIP2.equalsIgnoreCase(name)) {
> return new BZip2CompressorInputStream(in,
> actualDecompressConcatenated);
>
Re: [EXEC] Help needed for regression testing ...
Hello Siegfried, On Wed, Apr 9, 2008 at 8:47 AM, Siegfried Goeschl <[EMAIL PROTECTED]> wrote: > Hi folks, > > commons-exec (see http://commons.apache.org/sandbox/exec/) is about running > external processes from within a JVM - and there are a lot of OS and JVM > versions out there (plus a lot of code in commons-exec to handle this). > > So if you feel adventurous and have some time to spare ... > > +) I uploaded a self-contained test distribution to > http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip > +) If you unpack the zip file you are able to start the regression tests > using 'sh ./testme.sh" or 'testme.bat' > +) Make sure that you have $JAVA_HOME defined as environment variable to > pick up your Java installation to be used > +) It runs all regression tests without requiring to have ANT or Maven > installed > +) Send a quick feedback about the test result and the OS/JVM being used so > I can update the website I tested the zip on a couple of my boxes and all tests passed, the results are pasted below. Win Vista Ultimate 64 bit | JDK 1.3.1_20 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.4.2_17 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.5.0_15 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.5.0_15x64 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.6.0_05 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.6.0_05x64 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.7.0ea_b24 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.7.0ea_b24x64 - OK (55 tests) Win XP Pro 32 bit | JDK 1.4.2_17 - OK (55 tests) Win XP Pro 32 bit | JDK 1.5.0_15 - OK (55 tests) Win XP Pro 32 bit | JDK 1.6.0_05 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.4.2_17 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.5.0_15 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.6.0_05 - OK (55 tests) Hope this helps. > > Thanks in advance > > Siegfried Goeschl > > PS: Please, don't run the tests on a mission-critical & super-important box > - some of the tests are quite heavy (e.g. starting thousand processes to > make sure that we don't have any memory/handle leaks) > > Regards, Bindul -- Bindul Bhowmik | MindTree Ltd. | www.mindtree.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
