On Fri, Oct 14, 2016 at 2:38 PM, Antonin Stefanutti
wrote:
>
>> On 14 Oct 2016, at 14:35, Luca Burgazzoli wrote:
>>
>> An option would be to move before/after/between in StringHelper and
>> wrapping them in ObjectHelper with @Deprecated annotation, the
>> proposed new methods should go straight t
I've logged two JIRA:
- https://issues.apache.org/jira/browse/CAMEL-10389 --> Move some
function to Stringhelper (target 2.19)
- https://issues.apache.org/jira/browse/CAMEL-10390 --> Enhance
before/after/between (target 2.18.1)
---
Luca Burgazzoli
On Fri, Oct 14, 2016 at 2:38 PM, Antonin Stefanu
> On 14 Oct 2016, at 14:35, Luca Burgazzoli wrote:
>
> An option would be to move before/after/between in StringHelper and
> wrapping them in ObjectHelper with @Deprecated annotation, the
> proposed new methods should go straight to StringHelper.
I didn’t dare to propose you that but that’s exa
An option would be to move before/after/between in StringHelper and
wrapping them in ObjectHelper with @Deprecated annotation, the
proposed new methods should go straight to StringHelper.
---
Luca Burgazzoli
On Fri, Oct 14, 2016 at 2:25 PM, Antonin Stefanutti
wrote:
> Hi Luca,
>
> Make sense to
Hi Luca,
Make sense to me. As I refactored Camel CDI with Java 8 in Camel 2.18.0, I
found using Optional as return type of internal util methods quite useful in
term of client conciseness / readability compared to null handling.
I’m wondering whether that should be added to StringHelper instead