Re: A release train...
> Note on this guys. Most of us are fairly busy folks, working to squeeze this > pro-bono work in edgewise. For example I have a wife, a 4 year old, a 6 year > old and a parent in a wheelchair to take care of...along with my day job to > keep the ball rolling forward. That said, we definitely appreciate everyone’s > care and support here. We’ll keep trying to chip away at those components. My > current list is: > Totally understood and relatable. Thanks for all your work :-) -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE][RESULT] Release Apache Commons Geometry 1.0-beta1 based on RC3
This vote passes with the following votes: +1 Bruno Kinoshita (binding) +1 Baljit Singh (non-binding) +1 Rob Tompkins (binding) +1 Gilles Sadowski (binding) I will proceed with the release and send an announcement 24 hours after it is complete. Regards, Matt Juntunen
Re: [LANG] Null-safe 'operator'
Sure, thanks for the help.
Best,
Juraj+
On Sun, 19 Jul 2020, 10:22 Rob Spoor, wrote:
> If you want to use a default, I would put that in the orElse method
> (unless you want to use a default intermediate result). If it's
> something that needs to be calculated, use orElseGet.
>
>
> On 18/07/2020 23:05, Juraj Jurčo wrote:
> > Hi Rob,
> > thanks for the proposal. Yes, you're right I can use this. I haven't seen
> > it before nor realize it.
> > It also evokes the question whether it's self explanatory. Maybe it was
> > only me who didn't know it, but I haven't seen either of my colleagues
> use
> > it.
> > I see you can use also defaults as:
> > Optional.ofNullable(object)
> > .map(ObjectType::getProperty).or(() ->
> Optional.of(DEFAULT_PROPERTY))
> > .orElse(null);
> > It seems to me a bit heavy, but I agree, it's possible.
> >
> > So you would recommend not including it in the library?
> >
> > Thanks,
> > Juraj+
> >
> >
> > On Sat, 18 Jul 2020 at 15:44, Rob Spoor wrote:
> >
> >> Can't you just use java.util.Optional? That was added way back (ahum) in
> >> Java 8.
> >> Converting your example:
> >>
> >> SubSubSubProperty value = Optional.ofNullable(object)
> >> .map(ObjectType::getProperty)
> >> .map(Property::getSubProperty)
> >> .map(SubProperty::getSubSubProperty)
> >> .map(SubSubProperty::getSubSubSubProperty)
> >> .orElse(null);
> >>
> >>
> >> On 18/07/2020 14:28, Juraj Jurčo wrote:
> >>> Hi guys,
> >>> I'm new in this list and I would like to contribute to Apache commons.
> >>> First of all I would like get some feedback if it makes sense to
> >> contribute.
> >>>
> >>> Java is slow in implementation of null-safe operator however sometimes
> >> it's
> >>> really needed. So far I didn't find any implementation of this in any
> >>> library and I think it can be useful for many developers.
> >>>
> >>> To the point, instead of writing something like:
> >>> if(object != null
> >>> && object.getProperty() != null
> >>> && object.getProperty().getSubProperty() != null
> >>> && object.getProperty().getSubProperty().getSubSubProperty()
> !=
> >>> null ){
> >>> Object value =
> >>>
> >>
> object.getProperty().getSubProperty().getSubSubProperty().getSubSubSubProperty();
> >>> }
> >>>
> >>> I would like to turn it into something like this:
> >>> Object value = ObjectUtils
> >>> .nullish(object)
> >>> .nullish(object::getProperty)
> >>> .nullish(Property::getSubProperty)
> >>> .nullish(SubProperty::getSubSubProperty)
> >>> .get(SubSubProperty::getSubSubSubProperty);
> >>>
> >>> The idea is to return null in the case any property 'on the way'
> returns
> >>> null. I can implement it with defaults as well.
> >>>
> >>> Do you have some objections to the implementation? Do you know if it
> >>> already exists somewhere?
> >>>
> >>> Thanks for your feedback,
> >>> best, Juraj+
> >>>
> >>
> >>
> >> -
> >> 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: [fileupload] Re: A release train...
Alright! I was expecting a minor release 1.5 and forgot about the version bump in FileUpload. Yes, it doesn't make sense for a new release, especially with the new major version. My patch was also the reason for my curiosity though ;) Thanks Gary for all the releases, PRs, and mails :) On Sun, 19 Jul, 2020, 2:43 pm Stefan Bodewig, wrote: > On 2020-07-18, Merbin J Anselm wrote: > > > Well. Commons Fileupload's last release was in December 2018 and it has > > been released at least once a year before that. My thoughts were on this > > line > > Well, the question is whether there have been changes that would warrant > a new release at all. It hasn't seen that mayn commits the past eighteen > months. > > I just had a very quick look at the commits since the last release and > one of the first things done was bumping the major version. So if > anybody cut a release from the master branch it would not be compatible > with 1.4 at all. Not sure this would help anybody. > > As far as changes go I see your (Merbin's) FILEUPLOAD-274, adding > support for Jakarta API coordinates and some performance > improvements. I'm not sure whether this is all the people looking after > fileupload (I'm not one of them) had planned for a new major version. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: A release train...
Commons BeanUtils2 Which we can then upgrade Commons Config to use BeanUtils2. On 7/18/2020 9:00 AM, Gary Gregory wrote: Hi All, We've just released Commons Lang 3.11. My goal is to release Text very soon. When Phil is done with his work on Pool, release Pool, then DBCP. I also want to look at Crypto again where building the different binaries is a challenge but I think I am getting close. There is also CSV that is probably ready or close to ready for a release. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: A release train...
> On Jul 19, 2020, at 6:20 AM, Bruno P. Kinoshita wrote: > > Thanks for helping with so many releases (and issues, PR's, mails, etc :) > Gary! +1 > > I'll prepare an alpha2 for [imaging] soon too. > > > Thanks > > Bruno > > > > > > On Sunday, 19 July 2020, 1:00:42 am NZST, Gary Gregory > wrote: > > > > > > Hi All, > > We've just released Commons Lang 3.11. My goal is to release Text very > soon. When Phil is done with his work on Pool, release Pool, then DBCP. > > I also want to look at Crypto again where building the different binaries > is a challenge but I think I am getting close. > > There is also CSV that is probably ready or close to ready for a release. > > 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
Re: A release train...
Thanks for helping with so many releases (and issues, PR's, mails, etc :) Gary! I'll prepare an alpha2 for [imaging] soon too. Thanks Bruno On Sunday, 19 July 2020, 1:00:42 am NZST, Gary Gregory wrote: Hi All, We've just released Commons Lang 3.11. My goal is to release Text very soon. When Phil is done with his work on Pool, release Pool, then DBCP. I also want to look at Crypto again where building the different binaries is a challenge but I think I am getting close. There is also CSV that is probably ready or close to ready for a release. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[fileupload] Re: A release train...
On 2020-07-18, Merbin J Anselm wrote: > Well. Commons Fileupload's last release was in December 2018 and it has > been released at least once a year before that. My thoughts were on this > line Well, the question is whether there have been changes that would warrant a new release at all. It hasn't seen that mayn commits the past eighteen months. I just had a very quick look at the commits since the last release and one of the first things done was bumping the major version. So if anybody cut a release from the master branch it would not be compatible with 1.4 at all. Not sure this would help anybody. As far as changes go I see your (Merbin's) FILEUPLOAD-274, adding support for Jakarta API coordinates and some performance improvements. I'm not sure whether this is all the people looking after fileupload (I'm not one of them) had planned for a new major version. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Null-safe 'operator'
If you want to use a default, I would put that in the orElse method
(unless you want to use a default intermediate result). If it's
something that needs to be calculated, use orElseGet.
On 18/07/2020 23:05, Juraj Jurčo wrote:
Hi Rob,
thanks for the proposal. Yes, you're right I can use this. I haven't seen
it before nor realize it.
It also evokes the question whether it's self explanatory. Maybe it was
only me who didn't know it, but I haven't seen either of my colleagues use
it.
I see you can use also defaults as:
Optional.ofNullable(object)
.map(ObjectType::getProperty).or(() -> Optional.of(DEFAULT_PROPERTY))
.orElse(null);
It seems to me a bit heavy, but I agree, it's possible.
So you would recommend not including it in the library?
Thanks,
Juraj+
On Sat, 18 Jul 2020 at 15:44, Rob Spoor wrote:
Can't you just use java.util.Optional? That was added way back (ahum) in
Java 8.
Converting your example:
SubSubSubProperty value = Optional.ofNullable(object)
.map(ObjectType::getProperty)
.map(Property::getSubProperty)
.map(SubProperty::getSubSubProperty)
.map(SubSubProperty::getSubSubSubProperty)
.orElse(null);
On 18/07/2020 14:28, Juraj Jurčo wrote:
Hi guys,
I'm new in this list and I would like to contribute to Apache commons.
First of all I would like get some feedback if it makes sense to
contribute.
Java is slow in implementation of null-safe operator however sometimes
it's
really needed. So far I didn't find any implementation of this in any
library and I think it can be useful for many developers.
To the point, instead of writing something like:
if(object != null
&& object.getProperty() != null
&& object.getProperty().getSubProperty() != null
&& object.getProperty().getSubProperty().getSubSubProperty() !=
null ){
Object value =
object.getProperty().getSubProperty().getSubSubProperty().getSubSubSubProperty();
}
I would like to turn it into something like this:
Object value = ObjectUtils
.nullish(object)
.nullish(object::getProperty)
.nullish(Property::getSubProperty)
.nullish(SubProperty::getSubSubProperty)
.get(SubSubProperty::getSubSubSubProperty);
The idea is to return null in the case any property 'on the way' returns
null. I can implement it with defaults as well.
Do you have some objections to the implementation? Do you know if it
already exists somewhere?
Thanks for your feedback,
best, Juraj+
-
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
