Hi,
I have a suggestion to a little bit improve ObjectUtils.getIfNull, can we
allow to pass Supplier varargs instead of Supplier, sometimes it is
very helpful, as well it will not break compatibility with the current
version.
As far as I understand I should write to you before creating a task, if
for what you want, you can simply use
getFirstNonNull(final Supplier... suppliers)
and then
defaultIfNull(final T object, final T defaultValue)
Yeldos Tanikin 于2020年6月15日周一 下午6:20写道：
> Hi,
> I have a suggestion to a little bit improve ObjectUtils.getIfNull, can we
> allow to pass Supplier varar
Sounds like a good idea, I am not sure on what would be a compatible signature,
Maybe an additional (Supplier, Supplier...)?
It's fine to open a pullrequest or task for simple enhancements like that,
especially if you have working code (with tests) already.
Gruss
Bernd
--
http://bernd.eckenfels
The best path forward is to provide a PR on GitHub so we can all see what
this concretely looks like.
Gary
On Mon, Jun 15, 2020, 07:01 Bernd Eckenfels wrote:
> Sounds like a good idea, I am not sure on what would be a compatible
> signature,
>
> Maybe an additional (Supplier, Supplier...)?
>
>
Hi Sven,
1. Yes, you can use RegionBSPTree3D.linecast to get the intersection of a
line or line subset with the boundaries of a region. That is the intended use
case. "Linecasting" is a superset of "raycasting". [1]
2. Yes, the LinecastPoint3D object that you get from linecasting contains
HI All,
I'd like to release 3.11 soon. I've not looked at the new Locks class yet
though.
Gary
Good stuff Gary! Couple questions.
Q1/ Will there be a follow-up post on behavioral compatibility too? :)
Q2/ Only component I'm working (meaning pushing for a release soon-ish) on at
the moment is [imaging] for some IIIF related stuff. Should we rename the
package from o.a.c.imaging to somethi
I can see filling in a small section for source compatibility but
behavioral compatibility is just too vague.
I kind of like inaging1 even if it is weird and even though we do not have
a precedent here in Commons. I'm curious what others think.
Gary
On Mon, Jun 15, 2020, 18:58 Bruno P. Kinoshita
> I kind of like inaging1 even if it is weird and even though we do not
have
> a precedent here in Commons. I'm curious what others think.
+1 from me.
Gary Gregory 于2020年6月16日周二 上午7:07写道：
> I can see filling in a small section for source compatibility but
> behavioral compatibility is just too
Hi.
> I'd like to release 3.11 soon.
First, please review [lang-1546]
https://github.com/apache/commons-lang/pull/428 when you (or other
committer) have time. It shall take no more than half hour to review it.
Second, like I said before, I do have a plan to refine StringUtils and
CharSequenceUti
I will take a look at that issue for Circuit Breakers using old swing/desktop
classes, and see if it can be deprecated so that we can use Java 9 modules
without requiring the java.desktop module too.
But not a blocker for 3.11, just nice to deprecate as soon as possible, to give
more time for
I would like to cut an RC in the next couple of days. There is no rush get
more PRs, there will always be more releases for your changes; -)
Gary
On Mon, Jun 15, 2020, 20:26 Xeno Amess wrote:
> Hi.
>
> > I'd like to release 3.11 soon.
>
> First, please review [lang-1546]
> https://github.com/ap
> I kind of like inaging1 even if it is weird and even though we do not have a
> precedent here in Commons. I'm curious what others think.
I think you are meaning imaging1 instead of inaging1 :)
Indeed imaging1 is kind of weird but looks good to me. +1
On June, 16, 2020, at 7:06 , Gary Gregory
13 matches
Mail list logo
