Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Duncan Jones]

On Fri, 9 Jun 2017 at 02:35, Gary Gregory  wrote:

> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  wrote:
>
> > There is a one other compatibility issue, which can be seen in the
> attached
> > code:
> >
> > import java.nio.charset.StandardCharsets;
> >
> > public class Weasel {
> >
> > private static final String US_ASCII = "US-ASCII";
> > private static final String UTF_8 = "UTF-8";
> > private static final String STANDARD_US_ASCII =
> > StandardCharsets.US_ASCII.name();
> > private static final String STANDARD_UTF_8 =
> > StandardCharsets.UTF_8.name
> > ();
> >
> > public static void main(String[] args) {
> >
> > switch (args[0]) {
> > case US_ASCII:
> > System.out.println("USA! USA!");
> > break;
> > case UTF_8:
> > System.out.println("Emoji Lovin' Hippies!");
> > break;
> > default:
> > System.out.println("Weirdo.");
> > }
> > }
> > }
> >
> >
> > This code compiles.
> > However, if the case labels are changed to STANDARD_US_ASCII and
> > STANDARD_UTF_8, the compilation will fail, because the  case labels are
> no
> > longer constant expressions.
> > In the actual code, this means that code compiled against an older
> version
> > of the library would work against the new code (because the old strings
> had
> > already been inlined), but could not be re-compiled.
> >
>
> Thank you for doing this research and POC :-)
>
> But Ugh! :-( We shot ourselves in the foot here.


D'oh. Sorry about that guys :-(


>
> Benedikt, how do you feel about a fix and a new RC?
>
> Gary
>
>
> >
> > I don't know why anyone would be doing this...
> >
> >  (CLIRR pre-dates string switches)
> >
> > Simon
> >
> > On Thu, Jun 8, 2017 at 5:10 PM, sebb  wrote:
> >
> > > On 8 June 2017 at 18:09, Gary Gregory  wrote:
> > > > On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> > > >
> > > >> On 8 June 2017 at 17:19, Gary Gregory 
> wrote:
> > > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> > > wrote:
> > > >> >
> > > >> >> [A Note, not a vote :) ]
> > > >> >>
> > > >> >> 1. Clirr is generally considered obsolete, as it hadn't been
> worked
> > > on
> > > >> for
> > > >> >> about ten years.   japicmp is a good replacement, especially for
> > > report
> > > >> >> generation, and is used in other commons projects.
> > > >> >>
> > > >> >
> > > >> > IIRC, we've started using japicm here and there. Each component
> can
> > > >> decide.
> > > >> > But yes, Clirr looks pretty dead.
> > > >> >
> > > >> >
> > > >> >> 2. Are the "changes" to the values in CharEncoding really
> > > necessary[1]
> > > >> (The
> > > >> >> deprecation surely is). Technically this is a potentially
> breaking
> > > >> binary
> > > >> >> incompatible change, as constant strings and primitives are
> inlined
> > > at
> > > >> >> compile time. [2]
> > > >> >> In this particular case, the results of load-time evaluation of
> the
> > > new
> > > >> >> initialization expressions  are identical to the old constants,
> so
> > > it's
> > > >> >> behaviourally compatible; however, since this is the case, and
> > since
> > > >> it's
> > > >> >> all deprecated anyway, why not leave the old values in-place?
> > > >> >>
> > > >> >
> > > >> > The changes are not "necessary" that for sure and we do get Clirr
> > > >> warnings:
> > > >> >
> > > >> > Value of field ISO_8859_1 is no longer a compile-time constant
> > > >> > Value of field US_ASCII is no longer a compile-time constant
> > > >> > Value of field UTF_16 is no longer a compile-time constant
> > > >> > Value of field UTF_16BE is no longer a compile-time constant
> > > >> > Value of field UTF_16LE is no longer a compile-time constant
> > > >> > Value of field UTF_8 is no longer a compile-time constant
> > > >> >
> > > >> > It's source compatible. What is the issue at runtime that could
> hurt
> > > >> users?
> > > >>
> > > >> As the OP wrote, constants are inlined by the compiler.
> > > >> So unless all code is recompiled, if it referenced the constant it
> may
> > > >> have a stale value.
> > > >> That is not binary compatible.
> > > >>
> > > >
> > > > But in this case the actual values are the same are they not? So what
> > is
> > > > the difference? Would this only be a problem if we changed the string
> > > > values?
> > >
> > > AFAIK the compiler only inlines compile-time constants.
> > > So going forward, the values won't be inlined.
> > > I assume the behaviour will be unaffected since the runtime value
> > > should be the same as the constant.
> > >
> > > The release notes really ought to explain why the Clirr report items
> > > aren't a problem.
> > >
> > > > Which we can't since these are defined in the JRE. And the JRE is
> > > > unlikely to change those.
> > > >
> > > > Gary
> > > >
> > > >
> > > >>
> > > >> >
> > 

Re: [text] Correct RandomStringGenerator description of thread safety/immutability

[Duncan Jones]

> On 3 Jun 2017, at 09:55, sebb  wrote:
> 
> On 3 June 2017 at 08:40, Gilles  wrote:
>> Hi Duncan.
>> 
>> Can we really say that "RandomStringBuilder instances
>> are _immutable_ [...] if using the default random number
>> generator"?
>> Calling "nextInt" on the instance returned by
>>  ThreadLocalRandom.current()
>> does change some internal state...
> 
> Agreed, there must be some internal state for 'next' to have any meaning.
> 
>> [IOW, unless I'm missing something, I think that "immutable"
>> should not be mentioned at all in this Javadoc.]
> 
> +1
> 
> What's important here is the thread-safety aspect.

Thanks for the feedback guys, I’ve pushed an update to remove the offending 
docs.

> 
>> Regards,
>> Gilles
>> 
>> 
>> 
>> On Sat,  3 Jun 2017 06:03:05 + (UTC), djo...@apache.org wrote:
>>> 
>>> Repository: commons-text
>>> Updated Branches:
>>>  refs/heads/master ebb0cbe8c -> d04b0f6ff
>>> 
>>> 
>>> Correct RandomStringGenerator description of thread safety/immutability
>>> 
>>> The thread safety and immutability of RandomStringGenerator is dependent
>>> upon the external source of randomness, if set. Updated the Javadocs to
>>> reflect this.
>>> 
>>> Fixes: TEXT-84
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
>>> Commit:
>>> http://git-wip-us.apache.org/repos/asf/commons-text/commit/d04b0f6f
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/d04b0f6f
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/d04b0f6f
>>> 
>>> Branch: refs/heads/master
>>> Commit: d04b0f6ff469c1674d251c542028697db3ca48af
>>> Parents: ebb0cbe
>>> Author: duncan 
>>> Authored: Sat Jun 3 07:03:18 2017 +0100
>>> Committer: duncan 
>>> Committed: Sat Jun 3 07:03:18 2017 +0100
>>> 
>>> 
>>> --
>>> src/changes/changes.xml | 1 +
>>> .../java/org/apache/commons/text/RandomStringGenerator.java | 5 -
>>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>> 
>>> --
>>> 
>>> 
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/commons-text/blob/d04b0f6f/src/changes/changes.xml
>>> 
>>> --
>>> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
>>> index d3cc0df..7b65a6d 100644
>>> --- a/src/changes/changes.xml
>>> +++ b/src/changes/changes.xml
>>> @@ -46,6 +46,7 @@ The  type attribute can be
>>> add,update,fix,remove.
>>>   
>>> 
>>>   
>>> +>> dev="djones">RandomStringGenerator claims to be immutable, but
>>> isn't
>>>   
>>> 
>>>   
>>> 
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/commons-text/blob/d04b0f6f/src/main/java/org/apache/commons/text/RandomStringGenerator.java
>>> 
>>> --
>>> diff --git
>>> a/src/main/java/org/apache/commons/text/RandomStringGenerator.java
>>> b/src/main/java/org/apache/commons/text/RandomStringGenerator.java
>>> index 6aa6806..58ebfb8 100644
>>> --- a/src/main/java/org/apache/commons/text/RandomStringGenerator.java
>>> +++ b/src/main/java/org/apache/commons/text/RandomStringGenerator.java
>>> @@ -46,7 +46,10 @@ import org.apache.commons.lang3.Validate;
>>>  * String randomLetters = generator.generate(20);
>>>  * 
>>>  * 
>>> - * {@code RandomStringBuilder} instances are immutable and thread-safe.
>>> + * {@code RandomStringBuilder} instances are immutable and
>>> thread-safe if using the
>>> + * default random number generator (RNG). If a custom RNG is set by
>>> calling the method
>>> + * {@link Builder#usingRandom(TextRandomProvider)
>>> Builder.usingRandom(TextRandomProvider)}, thread-safety
>>> + * and immutability must be ensured externally.
>>>  * 
>>>  * @since 1.1
>>>  */
>> 
>> 
>> 
>> -
>> 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: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

[Duncan Jones]

On Thu, 1 Jun 2017 at 16:31, Amey Jadiye  wrote:

> +1 seems good to have in toolbox. pretty similar method I have seen in
> Commons text WordUtils.capitalize() almost similar logic we will need here
> ,just not to capitalize first word and join them all, I'm in favour of
> having this in WordUtils.


We've discussed deprecating WorldUtils once the wrapping methods are broken
out into separate classes. I'm in favour of an individual class to do this
work.


>
> Regards,
> Amey
>
> On Thu, Jun 1, 2017, 7:33 PM Rob Tompkins  wrote:
>
> > Hello all,
> >
> > Folks at my day job have a method that takes in a space delimited String
> > (or arbitrarily delimited string for that matter), and returns a camel
> > cased string. Is there any reason that this shouldn’t be in StringUtils?
> It
> > feels reasonable to me. What are folks thoughts?
> >
> > Cheers,
> > -Rob
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

[Duncan Jones]

On Thu, 1 Jun 2017 at 15:27, Gary Gregory  wrote:

> IMO camel casing is all about words so [text] WordUtils. But why not have a
> CamelCaseUtils instead?
>
> Gary


+1. IMO it belongs in TEXT (if anywhere) and we should avoid classes with
static methods.

Per our other conservation about case conversions, we should carefully
specify whether this uses upper- or title-case and how it behaves in
different locales.

OOI, what is your real world use case for this?

Duncan


>
> On Jun 1, 2017 7:14 AM, "Rob Tompkins"  wrote:
>
> >
> > > On Jun 1, 2017, at 10:11 AM, Gary Gregory 
> > wrote:
> > >
> > > Isn't this kind of stuff or anything camel case supposed to be in
> [text]
> >
> > I’m ok with that path as well. It feels like it’s on the line between the
> > two components. Either way, it sounds like you’re not opposed to adding
> it
> > to a component.
> >
> > Should it be TextUtils.toCamelCase(String str, char delimiter, boolean
> > capitalizeFirstLetter), or WordUtils maybe, if we were to put it in
> [text]?
> >
> > -Rob
> >
> > > these days?
> > >
> > > Gary
> > >
> > > On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:
> > >
> > >> Hello all,
> > >>
> > >> Folks at my day job have a method that takes in a space delimited
> String
> > >> (or arbitrarily delimited string for that matter), and returns a camel
> > >> cased string. Is there any reason that this shouldn’t be in
> > StringUtils? It
> > >> feels reasonable to me. What are folks thoughts?
> > >>
> > >> Cheers,
> > >> -Rob
> > >> -
> > >> 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: [VOTE] Promote TEXT to Proper

[Duncan Jones]

+1
(non-binding)


> On 4 Jan 2017, at 06:46, Benedikt Ritter  wrote:
> 
> Hello Rob,
> 
> Rob Tompkins  schrieb am Di., 3. Jan. 2017 um 20:40 Uhr:
> 
>> Hello all,
>> 
>> I propose that we move [text] to Commons Proper.
>> 
>> --
>> 
> 
> 
>> [x] +1 Move [text] to Commons Proper
>> 
> 
> Regards,
> Benedikt
> 
> 
>> [ ] +0 I am fine with this move
>> [ ] -0 I am not too keen, because ...
>> [ ] -1 I am against this move, because ...
>> --
>> 
>> This VOTE will remain open for a minimum of 72 hours.
>> 
>> Why this proposal? My points follow:
>> 
>> * [text] currently is the most active of the sandbox components.
>> 
>> * Since June of 2016, we have seen nine distinct authors of commits to the
>> repository.
>> 
>> * In my opinion, a [text] release will help to accommodate [lang] to
>> become a lighter more java language based component by removing a
>> considerable amount of, from the perspective of the arbitrary java
>> application developer, potentially rarely used text processing algorithms.
>> 
>> Cheers,
>> -Rob
>> -
>> 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: [TEXT] Pull WordUtils from 1.0?

[Duncan Jones]

> On 2 Jan 2017, at 19:34, Rob Tompkins <chtom...@gmail.com> wrote:
> 
> 
>> On Jan 2, 2017, at 1:32 PM, Duncan Jones <dun...@wortharead.com> wrote:
>> 
>> Hi all,
>> 
>> I'm currently refactoring WordUtils into several classes containing instance 
>> methods. 
> 
> Any rough estimate on timeline (e.g. minutes, hours, days, or weeks)?
> 
> -Rob

I'll probably have the first classes ready in a couple of weeks. But as the 
current WordUtils is a clone of Lang, there's no great loss in waiting, I 
think. 

> 
>> 
>> Should we pull it from 1.0 to avoid releasing it in 1.0 and deprecating in 
>> 1.1 or 1.2?
>> 
>> Duncan 
>> -
>> 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

[TEXT] Pull WordUtils from 1.0?

[Duncan Jones]

Hi all,

I'm currently refactoring WordUtils into several classes containing instance 
methods. 

Should we pull it from 1.0 to avoid releasing it in 1.0 and deprecating in 1.1 
or 1.2?

Duncan 
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [text] Complete test coverage for RandomStringGenerator

[Duncan Jones]

> On 27 Dec 2016, at 10:29, Gilles  wrote:
> 
> Hi.
> 
> On Tue, 27 Dec 2016 09:54:29 + (UTC), djo...@apache.org wrote:
>> Repository: commons-text
>> Updated Branches:
>>  refs/heads/master 1b3e44809 -> 0b1ca53b3
>> 
>> 
>> Complete test coverage for RandomStringGenerator
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/0b1ca53b
>> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/0b1ca53b
>> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/0b1ca53b
>> 
>> Branch: refs/heads/master
>> Commit: 0b1ca53b3e00e74364849a14372e4b3f57c2d3a0
>> Parents: 1b3e448
>> Author: duncan 
>> Authored: Tue Dec 27 09:54:19 2016 +
>> Committer: duncan 
>> Committed: Tue Dec 27 09:54:19 2016 +
>> 
>> --
>> .../org/apache/commons/text/RandomStringGeneratorTest.java | 6 ++
>> 1 file changed, 6 insertions(+)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/commons-text/blob/0b1ca53b/src/test/java/org/apache/commons/text/RandomStringGeneratorTest.java
>> --
>> diff --git
>> a/src/test/java/org/apache/commons/text/RandomStringGeneratorTest.java
>> b/src/test/java/org/apache/commons/text/RandomStringGeneratorTest.java
>> index 2ff7a67..36ce5e0 100644
>> --- a/src/test/java/org/apache/commons/text/RandomStringGeneratorTest.java
>> +++ b/src/test/java/org/apache/commons/text/RandomStringGeneratorTest.java
>> @@ -203,4 +203,10 @@ public class RandomStringGeneratorTest {
>> assertTrue(c == 'b');
>> }
>> }
>> +
>> +@Test
>> +public void testZeroLength() throws Exception {
>> +RandomStringGenerator generator = new
>> RandomStringGenerator.Builder().build();
>> +assertEquals("", generator.generate(0));
>> +}
>> }
> 
> A string of length zero hardly qualifies as random.
> Shouldn't "generate(0)" rather raise an exception?
> [I know that "nextInt(1)" is also not random, but what applies to a
> general-purpose low-level utility might not be the best option for
> applications that would use TEXT.]

I was following the Robustness principle. Asking for a zero-length string is 
odd, but as there was a way to interpret that request without throwing an 
exception, I did so.

Duncan

> 
> Regards,
> Gilles
> 
> 
> -
> 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: [text] Rename RandomStringBuilder and make it immutable and thread-safe.

[Duncan Jones]

> On 27 Dec 2016, at 08:45, djo...@apache.org wrote:
> 
> Repository: commons-text
> Updated Branches:
>  refs/heads/master 6f6da3467 -> 08ac56a50
> 
> 
> Rename RandomStringBuilder and make it immutable and thread-safe.
> 
> The RandomStringBuilder class was renamed to RandomStringGenerator. The
> class is now constructed using an inner Builder class, resulting in an
> immutable and thread-safe generator. The default random generator is now
> ThreadLocalRandom rather than Random.
> 
> The inner CodePointPredicate class was extracted into a separate class
> and renamed to CharacterPredicate. The commonly used predicates are now
> in a separate enum, CharacterPredicates.
> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/08ac56a5
> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/08ac56a5
> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/08ac56a5
> 
> Branch: refs/heads/master
> Commit: 08ac56a502adb0d274d02f9d97f394e4a5c5966e
> Parents: 6f6da34
> Author: duncan 
> Authored: Tue Dec 27 08:18:52 2016 +
> Committer: duncan 
> Committed: Tue Dec 27 08:42:48 2016 +
> 
> --
> .../apache/commons/text/CharacterPredicate.java |  37 ++
> .../commons/text/CharacterPredicates.java   |  52 +++
> .../commons/text/RandomStringBuilder.java   | 354 ---
> .../commons/text/RandomStringGenerator.java | 316 +
> .../commons/text/CharacterPredicatesTest.java   |  50 +++
> .../commons/text/RandomStringBuilderTest.java   | 235 
> .../commons/text/RandomStringGeneratorTest.java | 206 +++
> 7 files changed, 661 insertions(+), 589 deletions(-)
> ———

Apologies, should have split this into multiple commits but I got too far into 
it before I reached that conclusion!

> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-text/blob/08ac56a5/src/main/java/org/apache/commons/text/CharacterPredicate.java
> --
> diff --git a/src/main/java/org/apache/commons/text/CharacterPredicate.java 
> b/src/main/java/org/apache/commons/text/CharacterPredicate.java
> new file mode 100644
> index 000..fb23ac4
> --- /dev/null
> +++ b/src/main/java/org/apache/commons/text/CharacterPredicate.java
> @@ -0,0 +1,37 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.commons.text;
> +
> +/**
> + * A predicate for selecting code points. Implementations of this interface 
> must
> + * be thread safe.
> + * 
> + * @since 1.0
> + */
> +public interface CharacterPredicate {
> +
> +/**
> + * Tests the code point with this predicate.
> + * 
> + * @param codePoint
> + *the code point to test
> + * @return {@code true} if the code point matches the predicate,
> + * {@code false} otherwise
> + * @since 1.0
> + */
> +boolean test(int codePoint);
> +}
> \ No newline at end of file
> 
> http://git-wip-us.apache.org/repos/asf/commons-text/blob/08ac56a5/src/main/java/org/apache/commons/text/CharacterPredicates.java
> --
> diff --git a/src/main/java/org/apache/commons/text/CharacterPredicates.java 
> b/src/main/java/org/apache/commons/text/CharacterPredicates.java
> new file mode 100644
> index 000..7f38552
> --- /dev/null
> +++ b/src/main/java/org/apache/commons/text/CharacterPredicates.java
> @@ -0,0 +1,52 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by 

Re: [TEXT] Items to port from Lang

[Duncan Jones]

> On 21 Dec 2016, at 19:06, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Wed, Dec 21, 2016 at 11:02 AM, Duncan Jones <dun...@wortharead.com>
> wrote:
> 
>> 
>> 
>>> On 21 Dec 2016, at 18:57, Gary Gregory <garydgreg...@gmail.com> wrote:
>>> 
>>> On Wed, Dec 21, 2016 at 12:17 AM, Duncan Jones <dun...@wortharead.com>
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Looking through Lang, I don’t see too much that needs to come across to
>>>> Text.
>>>> 
>>>> - The string distance algorithms have already moved and can be
>> deprecated
>>>> in StringUtils, once 1.0 is released
>>>> - The remainder of StringUtils doesn’t feel like it belongs in Text
>>>> - RandomStringUtils has been ported / re-built; we can deprecate some or
>>>> all of the class when 1.0 is released
>>>> - WordUtils: I think most of this could come to Text, but preferably
>>>> refactored into several classes to avoid a big list of static methods
>>>> 
>>> 
>>> +1, WordUtils is an obvious candidate for transfer.
>>> 
>>> We can also consider if any of the classes that move over and candidates
>>> for a new design. For example, instead of all static methods, a class
>> could
>>> be configured with uppercase or lowercase processing. Or a certain
>> Locale.
>>> Methods would then be on the instance side instead of the static side.
>>> 
>>> Gary
>>> 
>> 
>> Yes, this is exactly what I have in mind :-)
>> 
> 
> Sweet! Got for it.
> 
> Happy Hols,
> Gary

Apparently what I need for Christmas is a pair of glasses :-)

WordUtils was ported across six weeks ago. However, I think it would benefit 
from being chopped into some instance classes, so I’ll start work on that and 
see if I can get there before 1.0 is released.


> 
> 
>> 
>>> 
>>>> 
>>>> What do you think? I’m happy to take a first effort at
>> porting/rebuilding
>>>> WordUtils.
>>>> 
>>>> Duncan
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
>> tl?ie=UTF8=1789=9325=1617290459&
>> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>>> 
>>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=
>> 1617290459>
>>> JUnit in Action, Second Edition
>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
>> tl?ie=UTF8=1789=9325=1935182021&
>> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
>>> 
>>> 
>>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=
>> 1935182021>
>>> Spring Batch in Action
>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
>> tl?ie=UTF8=1789=9325=1935182951&
>> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=
>> 1935182951>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
> 
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
> 
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [TEXT] Items to port from Lang

[Duncan Jones]

> On 21 Dec 2016, at 18:57, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Wed, Dec 21, 2016 at 12:17 AM, Duncan Jones <dun...@wortharead.com>
> wrote:
> 
>> Hi,
>> 
>> Looking through Lang, I don’t see too much that needs to come across to
>> Text.
>> 
>> - The string distance algorithms have already moved and can be deprecated
>> in StringUtils, once 1.0 is released
>> - The remainder of StringUtils doesn’t feel like it belongs in Text
>> - RandomStringUtils has been ported / re-built; we can deprecate some or
>> all of the class when 1.0 is released
>> - WordUtils: I think most of this could come to Text, but preferably
>> refactored into several classes to avoid a big list of static methods
>> 
> 
> +1, WordUtils is an obvious candidate for transfer.
> 
> We can also consider if any of the classes that move over and candidates
> for a new design. For example, instead of all static methods, a class could
> be configured with uppercase or lowercase processing. Or a certain Locale.
> Methods would then be on the instance side instead of the static side.
> 
> Gary
> 

Yes, this is exactly what I have in mind :-)

> 
>> 
>> What do you think? I’m happy to take a first effort at porting/rebuilding
>> WordUtils.
>> 
>> Duncan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
> 
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
> 
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [text] Clarify whether varargs are being used in test (squashes warning).

[Duncan Jones]

> On 21 Dec 2016, at 08:28, djo...@apache.org wrote:
> 
> Repository: commons-text
> Updated Branches:
>  refs/heads/master 120409051 -> 322fe2723
> 
> 
> Clarify whether varargs are being used in test (squashes warning).

Note: I’m really not a big fan of using reflection to inspect fields in a unit 
test. I’ll try to find a way to refactor this to test externally observable 
behaviour.

> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/322fe272
> Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/322fe272
> Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/322fe272
> 
> Branch: refs/heads/master
> Commit: 322fe272311bedffe4c2f5275c816cc196a74890
> Parents: 1204090
> Author: duncan 
> Authored: Wed Dec 21 08:28:47 2016 +
> Committer: duncan 
> Committed: Wed Dec 21 08:28:47 2016 +
> 
> --
> .../org/apache/commons/text/translate/AggregateTranslatorTest.java | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-text/blob/322fe272/src/test/java/org/apache/commons/text/translate/AggregateTranslatorTest.java
> --
> diff --git 
> a/src/test/java/org/apache/commons/text/translate/AggregateTranslatorTest.java
>  
> b/src/test/java/org/apache/commons/text/translate/AggregateTranslatorTest.java
> index f58f2da..6ac6622 100644
> --- 
> a/src/test/java/org/apache/commons/text/translate/AggregateTranslatorTest.java
> +++ 
> b/src/test/java/org/apache/commons/text/translate/AggregateTranslatorTest.java
> @@ -32,7 +32,7 @@ public class AggregateTranslatorTest {
> 
> @Test
> public void testNullConstructor() throws NoSuchFieldException, 
> IllegalAccessException {
> -final AggregateTranslator subject = new AggregateTranslator(null);
> +final AggregateTranslator subject = new 
> AggregateTranslator((CharSequenceTranslator[]) null);
> final Field field = 
> AggregateTranslator.class.getDeclaredField("translators");
> field.setAccessible(Boolean.TRUE);
> assertNull(field.get(subject));
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[TEXT] Items to port from Lang

[Duncan Jones]

Hi,

Looking through Lang, I don’t see too much that needs to come across to Text.

 - The string distance algorithms have already moved and can be deprecated in 
StringUtils, once 1.0 is released
 - The remainder of StringUtils doesn’t feel like it belongs in Text
 - RandomStringUtils has been ported / re-built; we can deprecate some or all 
of the class when 1.0 is released
 - WordUtils: I think most of this could come to Text, but preferably 
refactored into several classes to avoid a big list of static methods

What do you think? I’m happy to take a first effort at porting/rebuilding 
WordUtils.

Duncan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[TEXT] Support for generating random strings?

[Duncan Jones]

Hi,

A recent discussion on LANG/RNG[1] seems to have concluded that 
RandomStringUtils doesn’t belong in LANG and almost certainly not in RNG either.

Would there be any interest in creating a similar class within TEXT? I’d be 
happy to work on this and produce a first draft class.

To give a flavour of what I’m proposing, please see the linked mail threads and 
also the gist at 
https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff. Some of 
the predicate stuff I’ve proposed may have wider uses within TEXT and could 
warrant breaking out into its own class.
 
Thanks,
Duncan



[1] http://markmail.org/message/buhfuzb2tsc6k2z6
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

[Duncan Jones]

> On 18 Dec 2016, at 10:51, sebb  wrote:
> 
> On 18 December 2016 at 10:40, Pascal Schumacher
>  wrote:
>> Am 18.12.2016 um 11:23 schrieb sebb:
>>> 
>>> It's definitely too specialised for LANG.
>> 
>> I do not think this is too specialized for LANG. RandomStringUtils has been
>> part of LANG since 1.0, and this is just an improved version of existing
>> functionality.
> 
> I don't think RandomStringUtils itself belongs in LANG, now that there
> is a TEXT component.
> 
> Quite a few TEXT-like classes were added to LANG because there was nowhere 
> else.

I agree with this. Creating random strings is not really a missing feature from 
java.lang.*.

We should add a similar class to TEXT, but take the opportunity to simplify 
some of the complicated semantics of the current version. We can then 
deprecated RandomStringUtils and remove it in 4.0.


> 
>> 
>> 
>> -
>> 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: [LANG] [RNG] New Unicode-capable additions to RandomStringUtils

[Duncan Jones]

> On 18 Dec 2016, at 06:55, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> I thought we were talking about deprecating any random code in favor of
> Commons RNG?
> 
> Gary

I guess that depends on the scope of RNG. Our previous conversation about 
RandomUtils made sense (LANG-1299), since that was about the functionality 
offered by the generator itself.

If RNG will become a repository of things you could do with a random generator, 
rather than just implementations of the generators, then I agree with your 
suggestion. If not, then I could imagine this random string generation staying 
in Lang or perhaps moving to Text.

Duncan

> 
> On Dec 17, 2016 10:39 PM, "Duncan Jones" <dun...@wortharead.com> wrote:
> 
>> On reflection, a bad choice of subject line. The other methods are
>> Unicode-capable, but just very rooted in thinking about char data types.
>> 
>>> On 18 Dec 2016, at 06:38, Duncan Jones <dun...@wortharead.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I’ve created a variation of RandomStringUtils.random(), which generates
>> the specified number of code points (rather than chars).
>>> 
>>> Implementation can be seen here (https://gist.github.com/dmjones500/
>> da2f61a0234f428748417bf1443c0dff).
>>> 
>>> Signature is:
>>> 
>>> public static String randomUnicode(final int count, final int
>> minCodePoint, final int maxCodePoint,
>>>   final Set include, final Random random)
>>> 
>>> 
>>> Expected overloads:
>>> 
>>> 
>>> public static String randomUnicode(final int count, final int
>> minCodePoint, final int maxCodePoint, final Set include)
>>> public static String randomUnicode(final int count, final int
>> minCodePoint, final int maxCodePoint)
>>> public static String randomUnicode(final int count)
>>> 
>>> And possibly:
>>> 
>>> public static String randomNumberUnicode(final int count)
>>> public static String randomAlphabeticUnicode(final int count)
>>> public static String randomAlphanumericUnicode(final int count)
>>> 
>>> 
>>> Any complaints if I add this to the code base? I’ve possibly
>> overcomplicated the predicate stuff, however it seemed the most flexible
>> way to specify requirements on the letters. I’ve created two built-in
>> predicates, but more could be supported (and users can create their own).
>>> 
>>> Duncan
>> 
>> 
>> -
>> 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: [LANG] New Unicode-capable additions to RandomStringUtils

[Duncan Jones]

On reflection, a bad choice of subject line. The other methods are 
Unicode-capable, but just very rooted in thinking about char data types.

> On 18 Dec 2016, at 06:38, Duncan Jones <dun...@wortharead.com> wrote:
> 
> Hi all,
> 
> I’ve created a variation of RandomStringUtils.random(), which generates the 
> specified number of code points (rather than chars).
> 
> Implementation can be seen here 
> (https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff).
> 
> Signature is: 
> 
>  public static String randomUnicode(final int count, final int minCodePoint, 
> final int maxCodePoint,
>final Set include, final Random random)
> 
> 
> Expected overloads:
> 
> 
>  public static String randomUnicode(final int count, final int minCodePoint, 
> final int maxCodePoint, final Set include)
>  public static String randomUnicode(final int count, final int minCodePoint, 
> final int maxCodePoint)
>  public static String randomUnicode(final int count)
> 
> And possibly:
> 
>  public static String randomNumberUnicode(final int count)
>  public static String randomAlphabeticUnicode(final int count)
>  public static String randomAlphanumericUnicode(final int count)
> 
> 
> Any complaints if I add this to the code base? I’ve possibly overcomplicated 
> the predicate stuff, however it seemed the most flexible way to specify 
> requirements on the letters. I’ve created two built-in predicates, but more 
> could be supported (and users can create their own).
> 
> Duncan


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] New Unicode-capable additions to RandomStringUtils

[Duncan Jones]

Hi all,

I’ve created a variation of RandomStringUtils.random(), which generates the 
specified number of code points (rather than chars).

Implementation can be seen here 
(https://gist.github.com/dmjones500/da2f61a0234f428748417bf1443c0dff).

Signature is: 

  public static String randomUnicode(final int count, final int minCodePoint, 
final int maxCodePoint,
final Set include, final Random random)


Expected overloads:


  public static String randomUnicode(final int count, final int minCodePoint, 
final int maxCodePoint, final Set include)
  public static String randomUnicode(final int count, final int minCodePoint, 
final int maxCodePoint)
  public static String randomUnicode(final int count)

And possibly:

  public static String randomNumberUnicode(final int count)
  public static String randomAlphabeticUnicode(final int count)
  public static String randomAlphanumericUnicode(final int count)


Any complaints if I add this to the code base? I’ve possibly overcomplicated 
the predicate stuff, however it seemed the most flexible way to specify 
requirements on the letters. I’ve created two built-in predicates, but more 
could be supported (and users can create their own).

Duncan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Support recursion in ReflectionToStringBuilder and deprecate RecursiveToStringStyle?

[Duncan Jones]

> On 24 Nov 2016, at 22:13, Pascal Schumacher <pascalschumac...@gmx.net> wrote:
> 
> Am 23.11.2016 um 21:29 schrieb Duncan Jones:
>> To create a deep toString() representation of an object, one must use a 
>> combination of ReflectionToStringBuilder and RecursiveToStringStyle. IMO 
>> this confuses behaviour and presentation. LANG-1249 is an example of the 
>> problems the original design can cause - it’s not clear from the 
>> ReflectionToStringBuilder documentation whether RecursiveToStringStyle is 
>> able or willing to take notice of the excluded fields for inner objects.
>> 
>> I propose that the recursion behaviour is governed by the builder, not the 
>> ToStringStyle.
> IMHO this makes sense.
> 
> -Pascal

Thanks, Pascal. Any thoughts on this from others?

Duncan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Support recursion in ReflectionToStringBuilder and deprecate RecursiveToStringStyle?

[Duncan Jones]

Hi all,

To create a deep toString() representation of an object, one must use a 
combination of ReflectionToStringBuilder and RecursiveToStringStyle. IMO this 
confuses behaviour and presentation. LANG-1249 is an example of the problems 
the original design can cause - it’s not clear from the 
ReflectionToStringBuilder documentation whether RecursiveToStringStyle is able 
or willing to take notice of the excluded fields for inner objects.

I propose that the recursion behaviour is governed by the builder, not the 
ToStringStyle. Either a new class should be created (RecursiveToStringBuilder) 
or additional constructors should be added to ReflectionToStringBuilder to 
trigger recursion.

This would have the added benefit of allowing different styling options when 
recursion is employed. I’m a little concerned whether MULTI_LINE_STYLE would 
work correctly without an overhaul of the ToStringStyle class to include some 
kind of “depth” indicator. But I can dig into that further if there’s any 
interest in this idea.

What do people think about this? I tried to search the mail archives for some 
discussion around these classes, but couldn’t find anything. Apologies if this 
is well trodden ground.

Duncan 
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [text][lang] string escaping

[Duncan Jones]

> On 19 Nov 2016, at 15:38, Rob Tompkins  wrote:
> 
> 
>> On Nov 19, 2016, at 6:33 AM, Benedikt Ritter  wrote:
>> 
>> Hello Gray,
>> 
>> Gary Gregory  schrieb am Sa., 19. Nov. 2016 um
>> 01:07 Uhr:
>> 
>>> Just a thought:
>>> 
>>> Does all the current (and future) string escaping code (XML, HTML, ...)
>>> really belong in [lang]? Would it be more natural to have it in [text]?
>>> 
>> 
>> My view on the whole think currently is, that we put stuff that is related
>> to strings in Lang. Code that works on texts should go to Text. To me a
>> text is more than just a string. A text contains works, that make up
>> sentences, which in turn build paragraphs.
>> 
>> Using this description, I'd argue that escaping belongs into lang and not
>> into text, because it works on individual characters rather than on texts.
> 
> I think this is a difficult distinction to draw because fundamentally 
> anything that does sufficient text processing necessarily operates on a 
> character by character basis. I propose below a distinction more along the 
> lines of potential usage.
> 
>> 
>> But this would also raise the question if the various edit distance
>> algorithms works on texts or on strings. So maybe my distinction is not
>> good at all.
>> 
>> Do we need to better specify the scope of text?
> 
> I definitely agree with the sentiment that we should find a clear line of 
> distinction between lang and text with regards to strings. Some thoughts that 
> spring to mind are more in the terms of how the algorithms are to be used. 
> 
> So let’s consider the two extremes of the spectrum of string/word/text 
> algorithms. On one hand, we have utilities like “StringUtils.isBlank(String 
> s)” which is ubiquitously used in standard day to day and is a foundational 
> extension of java. On the other hand, we have algorithms like natural 
> language processing or statistical processing of words for analysis of 
> biological sequences (two chapters in M. Lothaire’s “Applied Combinatorics on 
> Words). The extremes seem to point towards day-to-day usage in any variety of 
> java applications, where as the other extreme seems to point to an 
> application that is specifically designed at string/word/text processing. I 
> don’t see folks in everyday usage wanting to find edit distance between two 
> strings unless they’re writing something specifically doing text processing 
> or something of that nature.
> 
> Now clearly the problem with this distinction is the amount of grey area that 
> it leaves in figuring out what goes where, so I don’t know if it’s the right 
> way to go. It was just the thought that came to mind.
> 
> Any thoughts out there?

I think you're on the right track here. Lang is supposed to plug the gaps in 
Java's core packages. A certain amount of text manipulation is expected in many 
applications, but once we get into the realms of statistical analysis or fuzzy 
comparison methods then we've moved beyond that. 

Perhaps a tongue-in-cheek definition of "if you had to consult a book to write 
that, it belongs in Text". 

Duncan

> 
> Cheers,
> -Rob
> 
>> 
>> Benedikt
>> 
>> 
>>> 
>>> Gary
>>> 
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <
>>> https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8
 
>>> 
>>> >> ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
>>> JUnit in Action, Second Edition
>>> <
>>> https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
 
>>> 
>>> >> ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
>>> Spring Batch in Action
>>> <
>>> https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
 
>>> >> ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
> 
> 
> -
> 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: [lang] Proposal: Allow extending DiffResult

[Duncan Jones]

On 3 March 2016 at 18:49, rgm  wrote:
> No, because ToStringStyle affects the rendering of only one of the object's
> toString methods and cannot change the "left differs from right" output,
> although it could change the rendering of either "left" or "right."  The
> inclusion of two objects and the hard-coded string "differs from" are not
> affected by ToStringStyle.

I think your current approach sounds just fine. `toString()` isn't
really intended for complex formatting tasks - the only reason I added
a `ToStringStyle` override was to match the style of other classes in
the builder package.

Composition is also generally preferred to inheritance, so I would
prefer not to make `DiffResult` extendable, but rather encourage you
to make methods in your own classes that know how to format a
`DiffResult` in the way you prefer.

Duncan

> On Thu, Mar 3, 2016 at 11:05 AM, Bhowmik, Bindul 
> wrote:
>
>> On Thu, Mar 3, 2016 at 9:31 AM, rgm  wrote:
>> > Ironically, it seems impossible to override DiffResult.toString(), which
>> > one may wish to do in order to provide alternate formats for the
>> > differences that are more compact than "lhs differs from rhs."
>> >
>> > In my case, I wanted to support differences between Set so that
>> > one could get output like:
>> > Object[groups:  added: {1, 2}, removed: {7},name:cat->dog]
>> >
>> > Rather than:
>> > Object[groups:[3,4,7],name=cat] differs from Object[groups:
>> > [1,2,3,4],name=dog]
>>
>> Isn't this a use case for building your own ToStringStyle [1] and
>> using the DiffResult#toString(ToStringStyle) method?
>>
>> >
>> > To support this I ended up wrapping the DiffResult class because I could
>> > not extend it due to its private constructor.
>> >
>> > re:
>> >
>> https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/DiffResult.html
>>
>> - Bindul
>>
>> [1]
>> https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ToStringStyle.html
>>
>> -
>> 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] Use of Review Patch

[Duncan Jones]

Hi folks,

Currently the Review Patch fix version seems to be applied whenever
code has been supplied in an issue. This includes situations where
agreement hasn't yet been reached on fixing the issue and where the
supplied patch is minimal at best.

I would prefer if we only use this marker on issues where the
discussions have already been completed and we've decided we want to
go ahead with the alteration/addition.

Do others agree with this? If so, I'll edit existing issues to match
this. I then plan to try and clean up some of the Discussion items,
so that we either close them or move them to Review Patch or Patch
Needed.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Use of Review Patch

[Duncan Jones]

On 15 April 2015 at 21:19, Paul Benedict pbened...@apache.org wrote:
 Odd way to use versions, imo. Sounds like discussion and review patch
 and patch needed tags would be the better tool.

I completely agree. But this has how it's been done historically in
Lang, so I wasn't trying to rock the boat too much with this
suggestion.

But if others agree, I'd be happy to make a more substantial change
that involves moving to Jira labels too.

Duncan



 Cheers,
 Paul

 On Wed, Apr 15, 2015 at 3:18 PM, Duncan Jones djo...@apache.org wrote:

 Hi folks,

 Currently the Review Patch fix version seems to be applied whenever
 code has been supplied in an issue. This includes situations where
 agreement hasn't yet been reached on fixing the issue and where the
 supplied patch is minimal at best.

 I would prefer if we only use this marker on issues where the
 discussions have already been completed and we've decided we want to
 go ahead with the alteration/addition.

 Do others agree with this? If so, I'll edit existing issues to match
 this. I then plan to try and clean up some of the Discussion items,
 so that we either close them or move them to Review Patch or Patch
 Needed.

 Duncan

 -
 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] testTimeZoneStrategyPattern() runs twice for no apparent gain

[Duncan Jones]

Hi everyone,

Lang takes a few minutes to build on my system, so I was examining
execution times of tests to see if anything can be improved.

I noticed that FastDateParserTest.testTimeZoneStrategyPattern() takes
quite a long time to execute (over 40 seconds for me). Then I noticed
this is executed twice, once for FastDateParserTest and once for the
subclass FastDateFormat_ParserTest. Yet the method doesn't appear to
use the result of getInstance(). As a result, we don't want this being
executed by subclasses as it gains us nothing.

Before I refactor this test, possibly into a separate
TimeZoneStrategyTest class, can anyone suggest a reason not to? Or a
better solution / location for the test?

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Lang 3.4 based on RC2

[Duncan Jones]

+0 (non-binding)

Built from zipped sources, digests look fine. JDK 1.8.0_40 on Win 8.1.
(Site build fails as mentioned already).
Site builds fine from JDK 1.7.0_75. For me the FindBugs page is blank,
not sure if that's to be expected?

97 skipped tests seems a little high (think this was mentioned on the
previous vote). FastDateParserSDFTest has 92 of them, although looking
at the source I see there are two @Ignore-ed tests (and 46 parameter
values), which explains it. I'd prefer we remove those tests (or
comment them out), but it's not a big problem.

Thanks for taking the effort to be RM, again.

Duncan


On 4 April 2015 at 09:12, Sergio Fernández wik...@apache.org wrote:
 +1 (non-binding)

 So far I've checked: signatures and digests. source release file layout,
 matched tags and commit ids, NOTICE and LICENSE files, build sources in a
 clean environment (maven 3.0.5, jdks 7u71-2.5.3 and 8.0_25, under debian
 64bits)


 On Fri, Apr 3, 2015 at 2:56 PM, Benedikt Ritter brit...@apache.org wrote:

 Hi all,

 We've worked through the issues identified in Commons Lang 3.4 RC1, so I
 would like to call a vote for releasing Commons Lang 3.4 based on RC2.

 The changes since RC1 are:
 - Fixed TimeZone related problem in test cases
 - Fixed broken windows OS detection in SystemUtils
 - Added OS X support to SystemUtils
 - Fixed Ant build
 - Added compatibility section to release notes explaining the change to the

 org.apache.commons.lang3.time.DurationFormatUtils.ISO_EXTENDED_FORMAT_PATTERN
 constant

 Commons Lang 3.4 RC2 is available for review here:
   https://dist.apache.org/repos/dist/dev/commons/lang/ (svn revision 8515)

 Maven artifacts are here:


 https://repository.apache.org/content/repositories/orgapachecommons-1086/org/apache/commons/commons-lang3/3.4/


 Details of changes since 3.3.2 are in the release notes:
   https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
   http://people.apache.org/~britter/lang-3.4-RC2/changes-report.html

 I have tested this with JDK 1.6, 1.7, 1.8 and 1.9 EA using maven 3. Note
 that the site build doesn't work with Java 8 and 9 due to problems with
 Clirr (clirr doesn't work with Java 8+).

 The tag is here:
   http://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_4_RC2/
 (svn
 1671054)

 Site:
   http://people.apache.org/~britter/lang-3.4-RC2/
   (note some *relative* links are broken and the 3.4 directories are not
 yet created - these will be OK once the site is deployed)

 Clirr Report (compared to 3.3.2):
   http://people.apache.org/~britter/lang-3.4-RC2/clirr-report.html

 RAT Report:
   http://people.apache.org/~britter/lang-3.4-RC2/rat-report.html

 KEYS:
   https://www.apache.org/dist/commons/KEYS

 Please review the release candidate and vote. This vote will close no
 sooner that 72 hours from now, i.e. after 15:00 CET 06-April 2015

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...

 Thanks!

 Benedikt

 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter




 --
 Sergio Fernández
 Partner Technology Manager
 Redlink GmbH
 m: +43 6602747925
 e: sergio.fernan...@redlink.co
 w: http://redlink.co

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PROPOSAL] Create new sandbox component Commons Crypto

[Duncan Jones]

On 18 March 2015 at 15:47, Phil Steitz phil.ste...@gmail.com wrote:

 On 3/18/15 5:57 AM, Duncan Jones wrote:
 Hi everyone,

 I would like to begin work on a new sandbox component, Commons Crypto,
 that makes it easier for developers to use crypto from the standard
 Java libraries. The component would have two goals: 1) To make it
 harder for users to make typical crypto errors, 2) To make it easier
 to perform common crypto tasks. Some select examples are below:

 Typical errors to avoid:
  - Weak conversion of passwords to keys.
  - Specifying algorithms that rely on system defaults.
  - Bad conversions of ciphertext to strings.
  - Encryption/decryption of strings without charsets.

 Common tasks that could be easier:
  - Specifying typical algorithms without figuring out AES/CBC/PKCS5Padding.
  - Working with X.509 certificates
  - Generating keys (particularly using password derivation).

 The scope of this library would be limited to the most commonly used
 algorithms, key sizes, etc. The goal is to satisfy 80-90% of potential
 use cases with a really well documented, compact library. Given that
 crypto is confusing to many, documentation will be exceptionally
 verbose.

 Two existing open-source libraries might spring to mind when
 considering this proposal: BouncyCastle [1] is a well-known crypto
 library with a Java implementation. However, this has different goals,
 namely to implement actual crypto algorithms. Commons Crypto, by
 contrast, is focussed on working with existing JDK implementations.
 JASYPT [2] is another library aimed at simplifying use of encryption,
 yet in my mind it goes too far, focussing only on password-based
 encryption, with limited control over how that's carried out.

 If no-one objects, I'll begin work on this component, asking the Infra
 team to create a new Git repository. Before committing any code, I'll
 follow the instructions at [3] to ensure this project is compliant
 with US Export Control Laws.

 Comments, thoughts and objections very welcome.

 Kind regards,

 Duncan


 [1] https://www.bouncycastle.org/java.html
 [2] http://www.jasypt.org/
 [3] http://www.apache.org/dev/crypto.html

 +1 to the idea.  Fits nicely into Commons, IMO.  Also have a look
 and maybe see if collaboration might be possible with Apache Shiro,
 which has a nice embedded, separately packaged crypto lib with sort
 of the same flavor as what you are describing (though probably more
 low-level).  And have a look at the already existing, but more
 limited scope (and really just BC wrapper) OpenPGP already in the
 sandbox.

Thanks for pointing out Apache Shiro - this seems quite interesting;
not sure how I missed it. They are certainly aiming to achieve similar
goals with their Cryptography component [1].

Perhaps it might be better for me to contribute to that project
instead. I need to get stuck into their API a little more deeply to
see what's available versus my concept for Commons Crypto.

Sorry for long delay in response, my mail filters are too aggressive
and I thought nobody had responded!

Duncan

[1] http://shiro.apache.org/cryptography-features.html


 Phil

 -
 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

[PROPOSAL] Create new sandbox component Commons Crypto

[Duncan Jones]

Hi everyone,

I would like to begin work on a new sandbox component, Commons Crypto,
that makes it easier for developers to use crypto from the standard
Java libraries. The component would have two goals: 1) To make it
harder for users to make typical crypto errors, 2) To make it easier
to perform common crypto tasks. Some select examples are below:

Typical errors to avoid:
 - Weak conversion of passwords to keys.
 - Specifying algorithms that rely on system defaults.
 - Bad conversions of ciphertext to strings.
 - Encryption/decryption of strings without charsets.

Common tasks that could be easier:
 - Specifying typical algorithms without figuring out AES/CBC/PKCS5Padding.
 - Working with X.509 certificates
 - Generating keys (particularly using password derivation).

The scope of this library would be limited to the most commonly used
algorithms, key sizes, etc. The goal is to satisfy 80-90% of potential
use cases with a really well documented, compact library. Given that
crypto is confusing to many, documentation will be exceptionally
verbose.

Two existing open-source libraries might spring to mind when
considering this proposal: BouncyCastle [1] is a well-known crypto
library with a Java implementation. However, this has different goals,
namely to implement actual crypto algorithms. Commons Crypto, by
contrast, is focussed on working with existing JDK implementations.
JASYPT [2] is another library aimed at simplifying use of encryption,
yet in my mind it goes too far, focussing only on password-based
encryption, with limited control over how that's carried out.

If no-one objects, I'll begin work on this component, asking the Infra
team to create a new Git repository. Before committing any code, I'll
follow the instructions at [3] to ensure this project is compliant
with US Export Control Laws.

Comments, thoughts and objections very welcome.

Kind regards,

Duncan


[1] https://www.bouncycastle.org/java.html
[2] http://www.jasypt.org/
[3] http://www.apache.org/dev/crypto.html

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE][LAZY] Migrate Apache Commons Lang to git

[Duncan Jones]

On 5 March 2015 at 10:13, Benedikt Ritter brit...@apache.org wrote:
 Hi,

 2015-03-05 0:40 GMT+01:00 sebb AT ASF s...@apache.org:

 On 3 March 2015 at 17:51, Benedikt Ritter brit...@apache.org wrote:
  Hi,
 
  2015-03-01 19:04 GMT+01:00 Benedikt Ritter brit...@apache.org:
 
  Hello,
 
  2015-01-06 18:55 GMT+01:00 sebb seb...@gmail.com:
 
  On 6 January 2015 at 17:24, Benedikt Ritter brit...@apache.org
 wrote:
   Hello Sebb,
  
   2015-01-06 18:01 GMT+01:00 sebb seb...@gmail.com:
  
   -1
  
   When the first components moved to Git, the agreement was that these
   would be used to iron out any problems and create some documentation
   to enable developers who know SVN to migrate to Git.
  
  
   The procedure I'm following here has been discussed already [1].
 
  That was after the original discussions.
 
  
  
   AFAICT there is no such documentation.
  
   It does not have to be extensive, just some details of commonly used
   SVN commands and their Git equivalents.
  
   For example:
  
   svn co, ci, status, diff, revert
   How to create a tag
  
  
   I'm not going to create such a how to use git documentation. I
 think
   everyone of us is capable of using google, stackoverflow and man
 pages.
   What you're looking for may be [2].
  
 
  Thanks, that's useful.
 
  
   Also what changes are needed to the pom.
  
  
   The only thing that has to be changed is the scm information (Luc,
  correct
   me, if I'm wrong here).
 
  Yes, but a worked example would help.
  Git seems to have lots of different URLs for the same thing.
 
  
  
   This would probably be best done as a Wiki page, at least initially.
  
  
   I think it is sufficient to update our release guide [3,4] to contain
  the
   equivalent git commands.
 
  That needs to be done, yes, but I was referring to developer use of
  Git; creating and applying patches etc.
 
   Since I'm the only one who has released [lang] for
   a year now and the [math] people already know how to do it, I don't
 see
   this as super critical. Or are you planning to RM for [lang] any time
  soon?
 
  No, I was not planning to RM Lang.
 
  However I would like to be able to commit fixes etc without having to
  spend a lot of time learning new commands.
 
   Would you be willing to withdraw your -1 if the release guide is
  updated?
 
  Yes, of course.
 
 
  Sorry that this took forever, I've been busy at work. But today I
 finally
  got some time to write something together [1]. There are still two open
  issues (retrieving all commits since the last release and git + maven
  release plugin). I'd like to ask the guys from [math] to add/correct
  anything missing/wrong.
 
  Is this enough for you to withdraw your proposal so that I can announce
  this lazy vote as passed?
 
 
  I've have published my changes to the release process documentation. I
  don't see a point in delaying this any longer, but I would feel better if
  sebb would comment on this once again, since he raised -1.

 I've just had a look at

 http://commons.apache.org/releases/prepare.html
 and
 http://commons.apache.org/releases/release.html

 I don't think they are quite ready.

 The prepare page has a missing entry TODO: Equivalent for git 
 This needs to be fleshed out please.

 It also says:

 
 Commons components [have] no need for a release branch ...
 All components using git should always use a release branch.
 If a release branch is taken then work will be required to merge any
 changes back into the trunk.
 

 The above does not explain why a release branch is needed when using
 Git, given that it appears to require additional work.

 
 Creating a release branch with git

 All git specific commands in the description below assume that you're
 on the release branch.

 git checkout -b release
 

 I don't understand what you're on the release branch means.
 Is that what the checkout command does? If so, does it have to be done
 in an empty directory?
 What is the command to create the release branch?
 How does one name a release branch in git?

 The release.html page syas:

 Final tag when using git

 Do the subsequent commands need to be done in a particular location,
 e.g. a clean directory?


 I'm feel pretty frustrated and left alone. I don't know the details of
 releasing lang with git (yet). I will have to figure out that when I'm
 doing it the first time. Math has already shown, that it is possible. I
 don't understand why you keep asking for explanation of git commands, which
 are well documented on the web. Give this proposal a chance. We're a patchy
 community and will figure this stuff out.

+1

At some point we need the release instructions, but otherwise our
developers should educate themselves about Git. There are plenty of
Git for Subversion users tutorials out there.

Thanks for taking the initiative to push this through.

Duncan




  Thanks you!
  Benedikt
 
 
 
  TIA!
  Benedikt
 
  [1] http://svn.apache.org/r1663139
 
 
 
   Regards,
   Benedikt
  
   [1] 

Re: [ALL] Too much traffic on the dev ML

[Duncan Jones]

On 17 January 2015 at 16:59, Ole Ersoy ole.er...@gmail.com wrote:
 GIlles,

 Well said as always.

 With respect to the goal of growing the community, I think everyone agrees
 that that's a good goal.
 So if we pick tools that developers are most likely to be used to, then they
 are more likely to join.

 The number of open source projects is growing everyday, and more and more
 developers are using github
 and stackoverflow facilities to get things done.  It's becoming the norm.

 So we developers arrive at Apache's github repository and see Watch turned
 off, it gives a backward appearance.

 Stackoverflow is great at:
 - Indexing questions
 - Providing a knowledge repository
 - Tagging and filtering content
 - Syntax highlighting content
 - Processing new questions and search previous answers

 This enhances the view of and intrinsic value of  the project that these
 services wrap.
 It's also a great secondary source of documentation and trails of
 experimentation.

 As a matter of fact I think if design discussions / questions were conducted
 on stackoverflow,
 everyone would be pleasantly surprised at the increase in sharp feedback.
 These individuals
 might subsequently join the community, because they find the design
 fascinating.

Stack Overflow is _not_ the right place to conduct design discussions
about Commons projects. Such questions would be closed, since
discussion is discouraged.

Also see this meta question, which discusses using SO as a support
forum: http://meta.stackexchange.com/q/3966/192221



 Cheers,
 - Ole


 On 01/17/2015 08:23 AM, Gilles wrote:

 On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:

 I agree - we're hung up on a clown from the 90s.  It's so much
 simpler click watch on github and get notifications.  Also
 stackoverflow has a much broader Java community and having traffic go
 through it could benefit this community.


 I'm afraid that the main problem is not the tool.

 Step 1: an issue is felt as a problem by some people (from the
 community or might-be contributors)
 Step 2: people (from the community) who don't feel the problem
 try to demonstrate that there isn't a problem, thus
 dismissing the (argumented) feeling of others

 This can destroy a community, or at least prevent its expansion.
 [And the Commons project's (with the word project as in an
 Apache project) community certainly does not benefit from a
 pool of contributors commensurate with its purported goal and
 user base.]

 On the practical side, I'm not (yet) against having a single dev
 list: discussions about design are usually interesting even if
 applied to another project's codebase (with the the word project
 as in programming project).

 But lately, the flood of automatic notifications (commits and CI)
 has drowned the useful discussions.
 For people who do not contribute to a project (i.e. neither
 providing code nor checking it), a commit diff is just noise
 because they lack context (not being aquainted with the codebase).

 The Commons community's implied answer to the stated fact is
 that people who feel that way should change their perception of
 reality, or go away.

 The respectful answer would be to solve the problem with the
 readily available technology of the 1990s: separate MLs for
 each project's _notifications_ (with the word project as in
 programming project).


 Regards,
 Gilles

 Ole

 On 01/16/2015 10:21 AM, Ben McCann wrote:

 I find the whole I idea of a mailing list very 1990s. I'd much prefer
 something like Google Groups where I can set my notification preferences
 easily to send me updates only on certain threads such as threads I've
 started, which has a nice easily browsable and searchable web interface,
 and where I do not have to go through a signup process for each new
 group/list I want to post to. I feel many of the problems folks are
 talking
 about here are caused by using a frustrating technology. E.g. it was
 mentioned that if we split mailing lists that joining every list would
 be
 very painful. Perhaps that's because the process of joining just a
 single
 list is too difficult. Having to setup filters is also not very
 user-friendly. How do I make a filter that says only put threads on
 which
 I've participated in my inbox? There's probably a way, but it's not as
 obvious as clicking a single button. And even with filters I still don't
 want most of this garbage coming to my mail account anyway because it
 pollutes my search results when I'm looking for something I do care
 about.
 I signed up for the dev list just so that I could ask that someone
 reviews
 and commits my patch https://issues.apache.org/jira/browse/BCEL-186
 (which
 I still need help with), but I really have no interest in getting any
 commons mail beyond that. I've never participated in any of these other
 projects and flooding my inbox is just frustrating and isn't going to
 cause
 me to start. The web interface for mailing list archives is truly
 horrendous.

Re: [ALL] Too much traffic on the dev ML

[Duncan Jones]

On 16 January 2015 at 14:54, Torsten Curdt tcu...@vafer.org wrote:
 Concerning [Math], when the possibility was raised, the majority
 thought that development within Commons had practical advantages
 (through shared burden of the development environment).

 I'm stating again the fact that nobody is involved in a Commons
 project programming-wise; hence it does not make sense, in principle,
 to have to share the programming discussions on the same ML.

 The conclusion you derive from the fact is only an opinion though.
 Maybe it does make sense for others to hear what's going on in Math?
 ...and be it just for the board reports?


 If it did, all the Apache (programming) project could as well share
 the same list. [We'd just have to set up filters, wouldn't we?]

 That comparison is pretty flawed as those projects are not tiny components.

 I've never a great fan of umbrellas but the components are so small -
 I don't see another option. The thought of components to go TLP feels
 just plain silly to me. Hence it would be great to work together as a
 community that takes care of those components.

 While from a practical standpoint (if everyone filters anyway) you
 might be right, my guess is that a community with many list will not
 have the same feeling of affiliation.

I think the sense of community achieved by receiving all emails is
minimal to nil. Most people appear to set up filters, which is a lot
of duplicated work and prone to error. I've missed emails before
because they were misspelled [ANOUNCE] , which didn't trigger my
filters. I could use the mail archives if I needed to see emails from
another component to which I'm not subscribed.

I would be in favour of total segregation, even including issues and
commits, but I appreciate the latter two might be challenging to
implement.

Duncan


 cheers,
 Torsten

 -
 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: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

[Duncan Jones]

On 18 December 2014 at 13:03, Mark Thomas ma...@apache.org wrote:
 On 18/12/2014 11:37, Jochen Wiedmann wrote:
 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.

 They should be able... yes.
 But does thatt mean we've got to enable it for all ASF now?

 Why not?

 I think we have far too many unnecessary, technical controls in Jira. If
 social controls are good enough for svn why aren't they good enough for
 Jira?

 Mark

I agree with Mark. The goal of opening up SVN access was to lower the
barrier to entry for other ASF developers. But a conscientious
developer would want to perform activity in Jira, so there is still a
barrier.

If we're talking about risks, access to SVN trumps Jira access any day, IMO.

Duncan



 -
 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: [DRAFT][ANNOUNCE] Apache Commons grants write access to all ASF committers

[Duncan Jones]

On 15 December 2014 at 08:25, Benedikt Ritter brit...@apache.org wrote:
 2014-12-15 4:02 GMT+01:00 Gary Gregory garydgreg...@gmail.com:

 Nice feedback all around. Here is a version that includes some of these
 thoughts:
 --

 Dear fellow committers,

 The Apache Commons Team is pleased to announce that write access to the
 Apache Commons Subversion and Git repositories has been granted to all ASF
 committers.

 Apache Commons is an Apache project focused on all aspects of reusable Java
 components. As such, the components maintained by the Apache Commons
 project
 may be of interest to a variety of other Apache projects.

 The Apache Commons community would like to invite you to share and maintain
 useful code.

 While Apache Commons is a Commit-Then-Review community, we would consider
 it polite and helpful for contributors to announce their intentions and
 plans on the dev mailing list before committing code.


 Have fun,

 The Apache Commons Community.
 --
 Gary


 Very nice! I'll send the announcement tonight.

+1 I think this is an excellent idea.



 Benedikt




 On Sun, Dec 14, 2014 at 3:13 PM, Gilles gil...@harfang.homelinux.org
 wrote:
 
  On Sun, 14 Dec 2014 12:57:02 -0700, Phil Steitz wrote:
 
  On 12/14/14 12:49 PM, Gilles wrote:
 
  On Sun, 14 Dec 2014 20:28:37 +0100, Benedikt Ritter wrote:
 
  Hi all,
 
  here is my draft for the announcement to committers@
 
  Regards,
  Benedikt
 
  --
 
  Dear fellow committers,
 
  the Apache Commons Team is pleased to announce that write access
  to the
  Apache Commons SVN and git repositories has been granted to all ASF
  committers.
 
  Apache Commons is an Apache project focused on all aspects of
  reusable Java
  components. As such the components maintained by the Apache
  Commons project
  may be of interest for a variety of other Apache projects.
 
  The Apache Commons community would like to invite you to share
  useful code
  which may be useful for other projects as well.
  Please let us know before you start working on the code, by
  writing a short
  mail to the dev mailing list [1].
 
 
  I'd be more careful (better safe than sorry) and add something like:
 
  [...] before committing code, consensus about the modifications
  should be
  reached on the dev ML.
 
 
  We are CTR so that is not necessary.  We might just want to refer to
  and update [1].
 
 
  IMHO, it is more efficient to discuss first (with the assumption that
  no objection amounts to green light).
 
   The upshot there is that before starting to commit
  to a component, it is polite to announce intention to start working
  on it and let people know what you have in mind.
 
 
  In the same vein, it is more polite to ask first whether there is an
  objection).
  It is also nicer, for all parties, to not have to veto a commit.
 
 
  Gilles
 
 
 
   Phil
 
  [1] http://wiki.apache.org/commons/CommonsEtiquette
 
 
 
  Thanks,
  Gilles
 
 
  Benedikt Ritter,
  on behalf of the Apache Commons community
 
  [1] http://commons.apache.org/mail-lists.html
 
 
 
 
  -
  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
 
 

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Do we need help?

[Duncan Jones]

On 29 Nov 2014 10:53, Benedikt Ritter brit...@apache.org wrote:

 Hi all,

 currently I feel really overwhelmed by the stuff I'd like to do at commons
 and the little time I can spend for it. Here is an (incomplete) list of
the
 things I'd like to work on:

 - get a new release of the build plugin out of the door for auto creating
 README.md and CONTRIBUTING.md
 - Work on [VALIDATOR] and get a new release out of the door
 - Work on [DBUTILS] and get a new release out of the door
 - Push [lang] 3.4 out of the door
 - Have a look at [compress] 2.0
 - Backport important fixes from [collections] 4.0 to 3.x and create a last
 service update
 - work on [text]
 - help releasing [imaging] 1.0
 - Improve docs on how to get involved at commons
 - Organize a logo contest for commons
 - ... many more

 I wonder how you feel about this. I have the feeling that a lot of people
 ask us to fix stuff and release components but we don't really catch up
 with this. This will give people the feeling that we are slow or we simply
 don't care.

Is the release process unnecessarily cumbersome for the RM? If so, perhaps
some time spent automating more of the procedure would be worthwhile.

Maybe we could consider some guidelines for when a release is needed. E.g.
After X fixes or Y new features then a release ought to happen unless there
is a strong reason not to.

Duncan

 Whenever I see someone posting on JIRA can you please fix this, we need
 this in out application and nobody is reacting, I feel tempted to jump
 right in, even if I don't know the component (which adds another entry to
 the list above).
 I don't see a way how we can improve this. My feeling is, that we need
more
 committers. But then I have the comments of people I've talked to in my
 ear: to old school, to difficult to get involved, to slow development
 process, to unwelcoming community. So what do we do? Do we need help?

 I'm excited to hear your thoughts :-)

 Best regards,
 Benedikt


 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Re: LANG-1052: Multiline recursive to string style

[Duncan Jones]

Hi Jan,

On 7 November 2014 05:39, Jan Matèrne (jhm) apa...@materne.de wrote:
 ping :)

 Jan

All the Lang developers are quite active on the mailing list, so you
can assume we've read your earlier email. However, we are busy people
with lives outside Apache Commons (the horror!), so it may take us a
few days to respond to a mail and longer still to review a patch :-)

I noticed you created the issue with a fix version of 3.4. We only
set a version in this field once the patch is applied, since we cannot
guarantee the patch will be applied before the release of an
intermediate version. I've updated this to the correct value for this
situation, which is Review Patch. Hopefully this will draw more
attention to your PR and one of us will get a chance to review it.

It will help us in reviewing and committing if you can create a SVN
patch file and attach it to the issue (see [1] for hints). We can't
merge PRs because our GitHub project is a read-only clone of the SVN
repos, so ultimately this is a step that has to be done by someone. If
you can do it, it speeds things up (particularly for folks like me who
don't bother to maintain a local clone of our GitHub stuff).

Duncan

[1] http://stackoverflow.com/a/13377540/474189



 -Ursprüngliche Nachricht-
 Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
 Gesendet: Dienstag, 4. November 2014 07:04
 An: dev@commons.apache.org
 Betreff: LANG-1052: Multiline recursive to string style

 I want to make some advertising for this pull request.

 It contains implementation, junit tests and already earned some
 positive feedback.



 Could someone do a review and (hopefully) merge the PR?



 cheers

 Jan



 [1] https://issues.apache.org/jira/browse/LANG-1052



 -
 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: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?

[Duncan Jones]

On 18 October 2014 06:25, Duncan Jones dun...@wortharead.com wrote:
 On 17 October 2014 23:41, James Sawle jamessa...@hotmail.com wrote:
 How do you create new implementations of such basic functionality that is so 
 explicitly defined within the API? It is like suggesting that we write 1+1 
 as 1+((1+1)-1) just to look different.

 I think sometimes it's about knowing you did it right. I will make a
 clean room implementation when I apply the patch. It will certainly
 look different anyway, since I'm not a personal fan of short if
 statements.


 They should also be made public as they are still useful for Java 6 and 
 prior (and unfortunately there are many houses that still depend on them) 
 and they will continue to persist!

 I agree. There is benefit to having them in the current release. Lang
 4.0 is probably some way off and many poor souls will be trapped in
 Java 6 (and hence Lang 3.x) for some time.

So, I went ahead and added these as non-deprecated, publicly
accessible methods. Happy to have that aspect discussed on the ML if
anyone wants to change it.

(These were clean room implementations just based on the Javadoc description).

 Just an off point, even if we can not use the implementations in a Java 7 
 situation. As the code has been copyrighted for Java 7 plus, do we not have 
 right to use it for Java 6 or before.

 IANAL, but I'm pretty sure the fact that we need this code because we
 have no access to Java 7 is not a reason for the licenses not to
 apply.

 Duncan

 Sent from my iPhone

 On 17 Oct 2014, at 23:25, sebb seb...@gmail.com wrote:

 On 17 October 2014 22:56, James Sawle jamessa...@hotmail.com wrote:
 Whilst the changes are the same as the Java 7 implementations, these in 
 fact came from OpenJDK implement ions and match the expected behaviour as 
 defined by the Javadoc. Any effort to change these so that that have less 
 resemblance to the Oracle implementation will just cause detrimental side 
 effects to performance.

 AIUI the OpenJDK license is GPLv2, which is not compatible with ALv2

 I think we need to create a clean-room implementation of the methods.

 These can be compared for speed against the OpenJDK versions.

 If they are much slower, then some effort might have to be expended to
 speed them up (again without reference to the JDK version).  Given
 that they are only needed temporarily, a minor slow-down is probably
 OK.

 We are not attempting to replace or capitalise Oracle functionality, but 
 merely polyfill it to precious Java versions. I think that the methods 
 should be removed as of Lang4 or if Java 7 becomes supported in Lang3 to 
 support this point.

 Yes, they should probably be removed when no longer needed.
 If they can be excluded from the public API then that will be easy.

 Sent from my iPhone

 On 17 Oct 2014, at 12:45, Duncan Jones djo...@apache.org wrote:

 Hi,

 James has authored a fine patch for LANG-536 (see below), but it does
 include some code that exactly matches Java 7 source. Specifically,
 the various compare(primitive, primitive) methods that have been added
 to BooleanUtils, NumberUtils and CharUtils are identical to the
 methods provided in Java 7 and above.

 Should we make some kind of syntactic changes to these methods to
 avoid being accused of plagiarism? For instance, we could replace the
 short-form if statements with the longer form. Or could we argue this
 is just the canonical form of the method?

 Kind regards,

 Duncan



 On 17 October 2014 01:02, jamessawle g...@git.apache.org wrote:
 GitHub user jamessawle opened a pull request:

   https://github.com/apache/commons-lang/pull/32

   Lang-536

   Added new isSorted methods to the ArrayUtils class, along with generic 
 implementations.

   Some of the primitive methods have needed reverse-engineered Java 7 
 'compare' methods from their wrappers, so these have been added to their 
 respective Utils classes.

 You can merge this pull request into a Git repository by running:

   $ git pull https://github.com/jamessawle/commons-lang LANG-536

 Alternatively you can review and apply these changes as the patch at:

   https://github.com/apache/commons-lang/pull/32.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

   This closes #32

 
 commit d5244ac66df9557ecb634a1478b4a7c29f2a1783
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:33:34Z

   LANG-536 Added new isSorted methods, both generic and primitive. Some 
 of the primitive methods require reverse-engineered compare methods due 
 to them not being added to their wrapper classes until Java 7. Tests for 
 these are to be added.

 commit af379292f30c4269dfb9b51882c5fc954ce84c49
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:56:59Z

   LANG-536 Added unit tests for new compare methods within Number, 
 Boolean and CharUtils.

 


 ---
 If your project is set up for it, you can reply

Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?

[Duncan Jones]

On 19 October 2014 07:04, Duncan Jones djo...@apache.org wrote:
 On 18 October 2014 06:25, Duncan Jones dun...@wortharead.com wrote:
 On 17 October 2014 23:41, James Sawle jamessa...@hotmail.com wrote:
 How do you create new implementations of such basic functionality that is 
 so explicitly defined within the API? It is like suggesting that we write 
 1+1 as 1+((1+1)-1) just to look different.

 I think sometimes it's about knowing you did it right. I will make a
 clean room implementation when I apply the patch. It will certainly
 look different anyway, since I'm not a personal fan of short if
 statements.


 They should also be made public as they are still useful for Java 6 and 
 prior (and unfortunately there are many houses that still depend on them) 
 and they will continue to persist!

 I agree. There is benefit to having them in the current release. Lang
 4.0 is probably some way off and many poor souls will be trapped in
 Java 6 (and hence Lang 3.x) for some time.

 So, I went ahead and added these as non-deprecated, publicly
 accessible methods. Happy to have that aspect discussed on the ML if
 anyone wants to change it.

 (These were clean room implementations just based on the Javadoc description).

FYI - my Jira access is borked (anyone else?) so I've not been able to
resolve LANG-536 yet. I'll do so when I'm next able to log in.


 Just an off point, even if we can not use the implementations in a Java 7 
 situation. As the code has been copyrighted for Java 7 plus, do we not have 
 right to use it for Java 6 or before.

 IANAL, but I'm pretty sure the fact that we need this code because we
 have no access to Java 7 is not a reason for the licenses not to
 apply.

 Duncan

 Sent from my iPhone

 On 17 Oct 2014, at 23:25, sebb seb...@gmail.com wrote:

 On 17 October 2014 22:56, James Sawle jamessa...@hotmail.com wrote:
 Whilst the changes are the same as the Java 7 implementations, these in 
 fact came from OpenJDK implement ions and match the expected behaviour as 
 defined by the Javadoc. Any effort to change these so that that have less 
 resemblance to the Oracle implementation will just cause detrimental side 
 effects to performance.

 AIUI the OpenJDK license is GPLv2, which is not compatible with ALv2

 I think we need to create a clean-room implementation of the methods.

 These can be compared for speed against the OpenJDK versions.

 If they are much slower, then some effort might have to be expended to
 speed them up (again without reference to the JDK version).  Given
 that they are only needed temporarily, a minor slow-down is probably
 OK.

 We are not attempting to replace or capitalise Oracle functionality, but 
 merely polyfill it to precious Java versions. I think that the methods 
 should be removed as of Lang4 or if Java 7 becomes supported in Lang3 to 
 support this point.

 Yes, they should probably be removed when no longer needed.
 If they can be excluded from the public API then that will be easy.

 Sent from my iPhone

 On 17 Oct 2014, at 12:45, Duncan Jones djo...@apache.org wrote:

 Hi,

 James has authored a fine patch for LANG-536 (see below), but it does
 include some code that exactly matches Java 7 source. Specifically,
 the various compare(primitive, primitive) methods that have been added
 to BooleanUtils, NumberUtils and CharUtils are identical to the
 methods provided in Java 7 and above.

 Should we make some kind of syntactic changes to these methods to
 avoid being accused of plagiarism? For instance, we could replace the
 short-form if statements with the longer form. Or could we argue this
 is just the canonical form of the method?

 Kind regards,

 Duncan



 On 17 October 2014 01:02, jamessawle g...@git.apache.org wrote:
 GitHub user jamessawle opened a pull request:

   https://github.com/apache/commons-lang/pull/32

   Lang-536

   Added new isSorted methods to the ArrayUtils class, along with 
 generic implementations.

   Some of the primitive methods have needed reverse-engineered Java 7 
 'compare' methods from their wrappers, so these have been added to 
 their respective Utils classes.

 You can merge this pull request into a Git repository by running:

   $ git pull https://github.com/jamessawle/commons-lang LANG-536

 Alternatively you can review and apply these changes as the patch at:

   https://github.com/apache/commons-lang/pull/32.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

   This closes #32

 
 commit d5244ac66df9557ecb634a1478b4a7c29f2a1783
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:33:34Z

   LANG-536 Added new isSorted methods, both generic and primitive. Some 
 of the primitive methods require reverse-engineered compare methods due 
 to them not being added to their wrapper classes until Java 7. Tests 
 for these are to be added.

 commit af379292f30c4269dfb9b51882c5fc954ce84c49
 Author: James Sawle jamessa

[ALL] How to handle GitHub pull requests

[Duncan Jones]

Hi everyone,

Some of our contributors like to use GitHub pull requests (PRs) as a
means of providing patches. Until now, I've tended to access the
.patch version of these pull requests and apply them in SVN.

Is there a preferred approach to take here? I have a GitHub account,
so presumably I could be given rights to the repositories I commit to
(lang) and this would allow me to merge PRs directly into trunk. Would
such changes be reflected in our SVN code-base too? Is there any
advantage to one approach over the other?

Apologies if this has already been discussed at length before - I
searched the mail archives but didn't come up with anything other than
passing references to our GitHub repositories.

Kind regards,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] How to handle GitHub pull requests

[Duncan Jones]

On 17 October 2014 09:07, Emmanuel Bourg ebo...@apache.org wrote:
 Le 17/10/2014 09:44, Duncan Jones a écrit :

 Is there a preferred approach to take here? I have a GitHub account,
 so presumably I could be given rights to the repositories I commit to
 (lang) and this would allow me to merge PRs directly into trunk. Would
 such changes be reflected in our SVN code-base too?

 This is not possible unfortunately, the SVN repositories mirrored on
 Github are read-only. And even if we converted all our repositories to
 Git, the commits would have to be pushed to the Apache master repository
 and not the Github mirror since they aren't synced back.

 Emmanuel Bourg

Thanks for the info, Emmanuel. I'll carrying on happily working with
the patch files then.

Do you happen to know if GitHub will react to commit messages from SVN
in order to close PRs, such as described in [1]? No worries if you
don't - I'll find out soon enough when I test it.

Duncan

[1] 
http://stackoverflow.com/questions/23015168/how-to-close-a-github-pull-request-with-a-commit-comment

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] New compare() methods in LANG-536 pull request match Java source - is this ok?

[Duncan Jones]

Hi,

James has authored a fine patch for LANG-536 (see below), but it does
include some code that exactly matches Java 7 source. Specifically,
the various compare(primitive, primitive) methods that have been added
to BooleanUtils, NumberUtils and CharUtils are identical to the
methods provided in Java 7 and above.

Should we make some kind of syntactic changes to these methods to
avoid being accused of plagiarism? For instance, we could replace the
short-form if statements with the longer form. Or could we argue this
is just the canonical form of the method?

Kind regards,

Duncan



On 17 October 2014 01:02, jamessawle g...@git.apache.org wrote:
 GitHub user jamessawle opened a pull request:

 https://github.com/apache/commons-lang/pull/32

 Lang-536

 Added new isSorted methods to the ArrayUtils class, along with generic 
 implementations.

 Some of the primitive methods have needed reverse-engineered Java 7 
 'compare' methods from their wrappers, so these have been added to their 
 respective Utils classes.

 You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/jamessawle/commons-lang LANG-536

 Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/commons-lang/pull/32.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

 This closes #32

 
 commit d5244ac66df9557ecb634a1478b4a7c29f2a1783
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:33:34Z

 LANG-536 Added new isSorted methods, both generic and primitive. Some of 
 the primitive methods require reverse-engineered compare methods due to them 
 not being added to their wrapper classes until Java 7. Tests for these are to 
 be added.

 commit af379292f30c4269dfb9b51882c5fc954ce84c49
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:56:59Z

 LANG-536 Added unit tests for new compare methods within Number, Boolean 
 and CharUtils.

 


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

 -
 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: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

[Duncan Jones]

On 17 Oct 2014 21:11, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Yes, that what i said we were not impacted even if the stack is big.

 Once again in theory you are right but in practise that's boring and
 creates averhead  for nothing.

You're not making a lot of sense here. Sebb explained a problem with your
approach, but your response is that he's right in theory, but that's boring?

I don't see how a multiple jar approach could work. Can you explain?

Duncan

 Le 17 oct. 2014 22:08, sebb seb...@gmail.com a écrit :

  On 17 October 2014 19:08, Romain Manni-Bucau rmannibu...@gmail.com
  wrote:
   I did it twice or more. it is not magic but the goal is to put
   removed/changed classes outside the core project (yes it implies some
   modules). this way the core part (what i call core here is what
   doesn't change) stays the same with same packages and only what moves
   changes.
 
  I still don't get it.
 
  Suppose you have the following method in the Item class:
 
  public int getLength()
 
  You want to change it to
 
  public long getLength()
 
  This is not binary compatible.
 
  Suppose I move the int version into a legacy jar.
  The long version is in the core jar.
  Both are in the same class.
 
  Now assume that appA uses the int version, and appB has been updated
  to use the long version.
 
  I don't see how one can make this work with Maven.
  The JVM classloader can only load a single version of the Item class.
 
  However appA needs one version, and appB needs the other.
 
  Note: I know that this can be made to work with OSGI (it uses multiple
  class-loaders) but that is a separate issue.
 
   I know it is easier to just change everything but then you can't cry
   cause the war does 200M to pring hello ;).
  
   Using maven pom dependencies can also make it smoother using the pom
   dependency as an aggregator.
  
   it wouldn't be commons which is (are actually) everywhere I wouldn't
   care that much but commons is so widely spread that it is a bit harder
   to manage (it is comparable to asm if it speaks to anyone).
 
 
  
  
   Romain Manni-Bucau
   @rmannibucau
   http://www.tomitribe.com
   http://rmannibucau.wordpress.com
   https://github.com/rmannibucau
  
  
   2014-10-17 20:02 GMT+02:00 Phil Steitz phil.ste...@gmail.com:
   On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
   Well maven showed the opposite. And this is clearly a theory vs
  practise
   topic so not sure it does worth allimenting this thread since well
not
  agree
  
   Top-posting this kind of statement does no good.  If you have a
   better approach, please describe it.
  
   Phil
   Le 17 oct. 2014 15:52, Matt Benson gudnabr...@gmail.com a écrit
:
  
   It's not just the broken parts that your dependencies may be using.
  The
   strategy Commons uses is the only way any of us know to permit
forward
   movement while avoiding jar hell.
  
   Matt
   On Oct 17, 2014 8:35 AM, Romain Manni-Bucau 
rmannibu...@gmail.com
   wrote:
  
   2014-10-17 15:28 GMT+02:00 Benedikt Ritter brit...@apache.org:
   2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau 
  rmannibu...@gmail.com:
  
   2014-10-17 13:52 GMT+02:00 Gary Gregory garydgreg...@gmail.com
:
   On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau 
   rmannibu...@gmail.com
   wrote:
  
   2014-10-17 12:23 GMT+02:00 Benedikt Ritter brit...@apache.org
:
   Hi,
  
   2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau 
   rmannibu...@gmail.com
   :
   snip
  
   In TomEE the stack uses [lang], then [lang3] was created and
  now
   TomEE
   needs [lang] + [lang3] where actually it only needs [lang]
   features,
   ie suppose package didn't change then we wouldn't have had
any
   issue.
   So it means you tend to import multiple versions of the same
  lib
   just
   cause few parts were broken even if it doesn't affect you.
   That's
   a
   bit sad IMO.
  
   If there is anything missing in lang3 that blocks you from
   migrating
   completely, can you tell us what that is? Maybe we can fix
   that...
   Issue is not in [commons] but in dependencies. The code we own
   migrated but not all our deps.
  
  
   I suggest you ask/Jira each dep to update their [lang] to the
   latest.
   That
   has worked for me in the past with different FOSS projects I've
  made
   the
   request about this and that libraries.
  
   Some projects will be receptive and at least reply to you right
   away,
   others won't. Patches help of course since will require at
least
   import
   changes.
  
   yep, main issue ATM is some can't or doesn't maitain the
version we
   use - excepted for security issues (we are bound to a EE version
  for
   instance). It meanse it will be forgotten in few years but it
also
   means we can get the same with [lang3] and [lang4] so clearly
   something to tackle at [commons] level. We can't just ask
  everybody to
   update each time IMHO.
  
   The alternative is, that TomEE won't run at all because of
  incompatible
   API
   changes. I would vote for the 

Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?

[Duncan Jones]

On 17 October 2014 23:41, James Sawle jamessa...@hotmail.com wrote:
 How do you create new implementations of such basic functionality that is so 
 explicitly defined within the API? It is like suggesting that we write 1+1 as 
 1+((1+1)-1) just to look different.

I think sometimes it's about knowing you did it right. I will make a
clean room implementation when I apply the patch. It will certainly
look different anyway, since I'm not a personal fan of short if
statements.


 They should also be made public as they are still useful for Java 6 and prior 
 (and unfortunately there are many houses that still depend on them) and they 
 will continue to persist!

I agree. There is benefit to having them in the current release. Lang
4.0 is probably some way off and many poor souls will be trapped in
Java 6 (and hence Lang 3.x) for some time.


 Just an off point, even if we can not use the implementations in a Java 7 
 situation. As the code has been copyrighted for Java 7 plus, do we not have 
 right to use it for Java 6 or before.

IANAL, but I'm pretty sure the fact that we need this code because we
have no access to Java 7 is not a reason for the licenses not to
apply.

Duncan

 Sent from my iPhone

 On 17 Oct 2014, at 23:25, sebb seb...@gmail.com wrote:

 On 17 October 2014 22:56, James Sawle jamessa...@hotmail.com wrote:
 Whilst the changes are the same as the Java 7 implementations, these in 
 fact came from OpenJDK implement ions and match the expected behaviour as 
 defined by the Javadoc. Any effort to change these so that that have less 
 resemblance to the Oracle implementation will just cause detrimental side 
 effects to performance.

 AIUI the OpenJDK license is GPLv2, which is not compatible with ALv2

 I think we need to create a clean-room implementation of the methods.

 These can be compared for speed against the OpenJDK versions.

 If they are much slower, then some effort might have to be expended to
 speed them up (again without reference to the JDK version).  Given
 that they are only needed temporarily, a minor slow-down is probably
 OK.

 We are not attempting to replace or capitalise Oracle functionality, but 
 merely polyfill it to precious Java versions. I think that the methods 
 should be removed as of Lang4 or if Java 7 becomes supported in Lang3 to 
 support this point.

 Yes, they should probably be removed when no longer needed.
 If they can be excluded from the public API then that will be easy.

 Sent from my iPhone

 On 17 Oct 2014, at 12:45, Duncan Jones djo...@apache.org wrote:

 Hi,

 James has authored a fine patch for LANG-536 (see below), but it does
 include some code that exactly matches Java 7 source. Specifically,
 the various compare(primitive, primitive) methods that have been added
 to BooleanUtils, NumberUtils and CharUtils are identical to the
 methods provided in Java 7 and above.

 Should we make some kind of syntactic changes to these methods to
 avoid being accused of plagiarism? For instance, we could replace the
 short-form if statements with the longer form. Or could we argue this
 is just the canonical form of the method?

 Kind regards,

 Duncan



 On 17 October 2014 01:02, jamessawle g...@git.apache.org wrote:
 GitHub user jamessawle opened a pull request:

   https://github.com/apache/commons-lang/pull/32

   Lang-536

   Added new isSorted methods to the ArrayUtils class, along with generic 
 implementations.

   Some of the primitive methods have needed reverse-engineered Java 7 
 'compare' methods from their wrappers, so these have been added to their 
 respective Utils classes.

 You can merge this pull request into a Git repository by running:

   $ git pull https://github.com/jamessawle/commons-lang LANG-536

 Alternatively you can review and apply these changes as the patch at:

   https://github.com/apache/commons-lang/pull/32.patch

 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:

   This closes #32

 
 commit d5244ac66df9557ecb634a1478b4a7c29f2a1783
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:33:34Z

   LANG-536 Added new isSorted methods, both generic and primitive. Some 
 of the primitive methods require reverse-engineered compare methods due 
 to them not being added to their wrapper classes until Java 7. Tests for 
 these are to be added.

 commit af379292f30c4269dfb9b51882c5fc954ce84c49
 Author: James Sawle jamessa...@hotmail.com
 Date:   2014-10-16T23:56:59Z

   LANG-536 Added unit tests for new compare methods within Number, 
 Boolean and CharUtils.

 


 ---
 If your project is set up for it, you can reply to this email and have 
 your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, 
 please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA

Re: [lang] LANG-975

[Duncan Jones]

On 9 October 2014 19:17, Benedikt Ritter brit...@apache.org wrote:
 I'm not fond that we need this method. However you're raising a good point.
 BooleanUtils only talks english. It understands yes and no but not
 ja and nein or oui and non. It would be nice to have a possibilty
 to make the toBoolean(String) method work for other langues.

We have toBoolean(str, trueString, falseString), which helps to some extent.

To make this class more universal, we could add an overload that
accepts Sets of strings for both false and true, meaning that
toBoolean(String) can be emulated for other languages and arbitrary
groups of true/false values. I'll raise an issue to suggest this.

Meanwhile, I've closed the currently discussed issue (975) since we
don't really have anyone in favour of it.



 OTOH this can easily be implemented in a custom MyAppBooleanUtils which
 delegates to commons BooleanUtils and passes the correct default values.

 2014-10-09 16:25 GMT+02:00 Filippo Balicchia fbalicc...@gmail.com:

 Hi James,
 IMHO I can't see the real need for this improvement,
 any way, I disagree with this case

 BooleanUtils.toBoolean(null, null) = true

 Regards

 --Filippo

 2014-10-09 9:49 GMT+02:00 James Sawle jamessa...@hotmail.com:
  I have created a patch for the above issue, which adds a new method
 signature to simplify the conversion from Strings to Booleans based upon a
 single true boolean String. This is therefore unlike the other methods,
 which either take no parameters (use a prebuilt list of true and false
 values), or require the user to provide a true, false and null value that
 the parameter must match.
  It has been pointed out by Duncan Jones, that this is jus syntactic
 sugar, due to it purely wrapping the StringUtils.equals method. Therefore
 the question is, whether having this simple method would drastically
 improve readability in calling code, or whether this would just be code
 bloat for the sake of it.
  Personally, there is another option, which would be to have a version of
 the method that takes a varargs of true values. This could therefore be
 more useful in general cases, and could be used to simplify some of the
 underlying String to boolean conversions. However, it should then be noted
 that this would just become a contains check, with added protection around
 null values. This would possibly also be more used to StringUtils with a
 wrapper method within the BooleanUtils, which again raises the question of
 code bloat.
  Any comments would be much appreciated.

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] LANG-975

[Duncan Jones]

On 14 October 2014 14:07, Duncan Jones djo...@apache.org wrote:
 On 9 October 2014 19:17, Benedikt Ritter brit...@apache.org wrote:
 I'm not fond that we need this method. However you're raising a good point.
 BooleanUtils only talks english. It understands yes and no but not
 ja and nein or oui and non. It would be nice to have a possibilty
 to make the toBoolean(String) method work for other langues.

 We have toBoolean(str, trueString, falseString), which helps to some extent.

 To make this class more universal, we could add an overload that
 accepts Sets of strings for both false and true, meaning that
 toBoolean(String) can be emulated for other languages and arbitrary
 groups of true/false values. I'll raise an issue to suggest this.

Now done, see: https://issues.apache.org/jira/browse/LANG-1048


 Meanwhile, I've closed the currently discussed issue (975) since we
 don't really have anyone in favour of it.



 OTOH this can easily be implemented in a custom MyAppBooleanUtils which
 delegates to commons BooleanUtils and passes the correct default values.

 2014-10-09 16:25 GMT+02:00 Filippo Balicchia fbalicc...@gmail.com:

 Hi James,
 IMHO I can't see the real need for this improvement,
 any way, I disagree with this case

 BooleanUtils.toBoolean(null, null) = true

 Regards

 --Filippo

 2014-10-09 9:49 GMT+02:00 James Sawle jamessa...@hotmail.com:
  I have created a patch for the above issue, which adds a new method
 signature to simplify the conversion from Strings to Booleans based upon a
 single true boolean String. This is therefore unlike the other methods,
 which either take no parameters (use a prebuilt list of true and false
 values), or require the user to provide a true, false and null value that
 the parameter must match.
  It has been pointed out by Duncan Jones, that this is jus syntactic
 sugar, due to it purely wrapping the StringUtils.equals method. Therefore
 the question is, whether having this simple method would drastically
 improve readability in calling code, or whether this would just be code
 bloat for the sake of it.
  Personally, there is another option, which would be to have a version of
 the method that takes a varargs of true values. This could therefore be
 more useful in general cases, and could be used to simplify some of the
 underlying String to boolean conversions. However, it should then be noted
 that this would just become a contains check, with added protection around
 null values. This would possibly also be more used to StringUtils with a
 wrapper method within the BooleanUtils, which again raises the question of
 code bloat.
  Any comments would be much appreciated.

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1628921 - /commons/proper/lang/trunk/src/changes/changes.xml

[Duncan Jones]

Thanks Benedikt, I'd better poke my IDE with a sharp stick. The XML
settings must be wrong.

On 2 October 2014 11:07,  brit...@apache.org wrote:
 Author: britter
 Date: Thu Oct  2 10:07:11 2014
 New Revision: 1628921

 URL: http://svn.apache.org/r1628921
 Log:
 Remove tab characters

 Modified:
 commons/proper/lang/trunk/src/changes/changes.xml

 Modified: commons/proper/lang/trunk/src/changes/changes.xml
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1628921r1=1628920r2=1628921view=diff
 ==
 --- commons/proper/lang/trunk/src/changes/changes.xml [utf-8] (original)
 +++ commons/proper/lang/trunk/src/changes/changes.xml [utf-8] Thu Oct  2 
 10:07:11 2014
 @@ -22,9 +22,9 @@
body

release version=3.4 date=tba description=tba
 -   action issue=LANG-827 type=update 
 dev=djonesCompareToBuilder's doc doesn't specify precedence of fields it 
 uses in performing comparisons/action
 +action issue=LANG-827 type=update dev=djonesCompareToBuilder's 
 doc doesn't specify precedence of fields it uses in performing 
 comparisons/action
  action issue=LANG-1000 type=fix dev=djonesParseException when 
 trying to parse UTC dates with Z as zone designator using 
 DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT/action
 -   action issue=LANG-1035 type=fix dev=djonesJavadoc for 
 EqualsBuilder.reflectionEquals() is unclear/action
 +action issue=LANG-1035 type=fix dev=djonesJavadoc for 
 EqualsBuilder.reflectionEquals() is unclear/action
  action issue=LANG-1020 type=update dev=britter due-to=Libor 
 OndrusekImprove performance of normalize space/action
  action issue=LANG-1033 type=add dev=ggregoryAdd 
 StringUtils.countMatches(CharSequence, char)/action
  action issue=LANG-1027 type=update 
 dev=rmannibucauorg.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast 
 should return true by default/action



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Thoughts on LANG-1039

[Duncan Jones]

Hi folks,
I'd welcome someone else's viewpoint on LANG-1039. The question is: what
should HashCodeBuilder.reflectionHashCode() do when given an array object
as input.

My argument is that the intended use of this method is for overriding
Object.hashCode() and so it should never be the case than an array object
is passed to this method. (It will always be this).

The complaint from the poster is that arrays return the result 17. This is
because arrays have no fields, so our reflection logic doesn't find
anything to add to the cumulative hash code.

I'm in favour of saying this isn't a problem, but it might be worth adding
something extra to the Javadocs to make it clearer how this method is
intended to be used and how it works. Something like If object has no
fields, the result will be a constant value (default = 17) or similar.

However, we could extend the method to recognise array types and return a
hashcode for the array.

I welcome thoughts on the matter.

Kind regards,

Duncan

Re: [LANG] Thoughts on LANG-1039

[Duncan Jones]

On 26 September 2014 14:53, Gary Gregory garydgreg...@gmail.com wrote:
 Let's also think about what happens when you to an array into a Map.

 Does the fact that we are dealing with a reflection hashCode API mean it
 should give the same key that would be used if you put the array in a map?

 Gary

Hi Gary, I don't entirely understand the point you are making there -
would you mind explaining further?

In the meantime, the original posters of LANG-1039 have admitted they
don't actually have a use case for passing arrays to this method.
They've simply spotted the odd result when they do.

I remain convinced the reflective builder is fine as it is, but
perhaps the Javadoc could be slightly clearer. I'll look to make an
edit to that.

Duncan




 On Fri, Sep 26, 2014 at 7:10 AM, Michael Pigott 
 mpigott.subscripti...@gmail.com wrote:

 Hi Duncan,
 Does it make sense to create a method specifically for array types,
 which calls reflectonHashCode on each element to compute a final hash code?
 This would solve the poster's problem and avoid polluting
 reflectionHashCode with the behavior.

 Regards,
 Mike
 On Sep 26, 2014 6:32 AM, Duncan Jones djo...@apache.org wrote:

  Hi folks,
  I'd welcome someone else's viewpoint on LANG-1039. The question is: what
  should HashCodeBuilder.reflectionHashCode() do when given an array object
  as input.
 
  My argument is that the intended use of this method is for overriding
  Object.hashCode() and so it should never be the case than an array object
  is passed to this method. (It will always be this).
 
  The complaint from the poster is that arrays return the result 17. This
 is
  because arrays have no fields, so our reflection logic doesn't find
  anything to add to the cumulative hash code.
 
  I'm in favour of saying this isn't a problem, but it might be worth
 adding
  something extra to the Javadocs to make it clearer how this method is
  intended to be used and how it works. Something like If object has no
  fields, the result will be a constant value (default = 17) or similar.
 
  However, we could extend the method to recognise array types and return a
  hashcode for the array.
 
  I welcome thoughts on the matter.
 
  Kind regards,
 
  Duncan
 




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Any objections to implementing LANG-1037?

[Duncan Jones]

Hi,

I raised https://issues.apache.org/jira/browse/LANG-1037 recently,
which would add support to StringUtils for joining lists of strings
with a different end separator. The idea is to support use cases such
as:

join([a, b, c], , ,  and ) = a, b and c.

Does anyone have any objections to me implementing this? My Jira issue
lists the three methods I would propose to add.

Kind regards,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Any objections to implementing LANG-1037?

[Duncan Jones]

On 11 September 2014 14:49, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, Sep 11, 2014 at 9:45 AM, sebb seb...@gmail.com wrote:

 On 11 September 2014 14:41, Gary Gregory garydgreg...@gmail.com wrote:
  To me, it feels out of scope for [lang]. I would never expect this to be
 in
  java.lang for example.

 Agreed.


 I see room in Commons for a [text] component for this kind of work.

 I would -1 this change and +1 [text].

 Gary

Ok, this sounds like a better idea. Thanks for the input.




  Gary
 
  On Thu, Sep 11, 2014 at 8:54 AM, Duncan Jones djo...@apache.org wrote:
 
  Hi,
 
  I raised https://issues.apache.org/jira/browse/LANG-1037 recently,
  which would add support to StringUtils for joining lists of strings
  with a different end separator. The idea is to support use cases such
  as:
 
  join([a, b, c], , ,  and ) = a, b and c.
 
  Does anyone have any objections to me implementing this? My Jira issue
  lists the three methods I would propose to add.
 
  Kind regards,
 
  Duncan
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Remove JDK 1.3 workaround from FieldUtils

[Duncan Jones]

Hi Benedikt,

On 26 August 2014 12:53,  brit...@apache.org wrote:
 Author: britter
 Date: Tue Aug 26 11:53:51 2014
 New Revision: 1620579

 URL: http://svn.apache.org/r1620579
 Log:
 Add fixme regarding a JDK 1.3 workaround

 Modified:
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java

 Modified: 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java?rev=1620579r1=1620578r2=1620579view=diff
 ==
 --- 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
  (original)
 +++ 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java
  Tue Aug 26 11:53:51 2014
 @@ -85,6 +85,7 @@ public class FieldUtils {
  public static Field getField(final Class? cls, final String fieldName, 
 final boolean forceAccess) {
  Validate.isTrue(cls != null, The class must not be null);
  Validate.isTrue(StringUtils.isNotBlank(fieldName), The field name 
 must not be blank/empty);
 +// FIXME is this workaround still needed? lang requires Java 6
  // Sun Java 1.3 has a bugged implementation of getField hence we 
 write the
  // code ourselves

Perhaps this is something to discuss on the ML. If we have sufficient
test coverage in that area, we could just remove the code and check it
still builds successfully using 1.6. Unless anyone shouts out with a
good reason why the code should stay.

Kind regards,

Duncan





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Fully recursive equals methods

[Duncan Jones]

Hi folks,

I'd like to implement recursive equals building [1] at some point in
the near future - I've seen a few people requesting/discussing this
feature on Stack Overflow.

Does anyone have any objections or reservations about this feature?

Kind regards,

Duncan

[1] https://issues.apache.org/jira/browse/LANG-1034

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Logo contest for Commons?

[Duncan Jones]

On 19 July 2014 05:04, Phil Steitz phil.ste...@gmail.com wrote:
 On 7/18/14, 1:55 AM, Benedikt Ritter wrote:
 Hi all,

 the Apache Commons project currently does not have it's own logo! We are
 simply reusing the Apache logo with the feather. I even remember a guy from
 legal say, that they don't like it very much when projects reuse the Apache
 feather for their logo.

 Huh?  Httpd just has a feather and their name.  Our current logo is
 the feather *plus* the name with the little tm thingy.  Seems
 perfectly legit to me as a logo.

 That said, this is a do-ocracy, so anyone who wants to propose
 something different, more power to them.

 Phil

I wanted to use the logo last year [1] in an advert on Stack Overflow
to drive more developers towards Commons projects (see [2] for the
2014 H2 competition). Because of the usage of the Apache Feather,
there was debate over whether the Commons logo could be used without
further permission. In the end I opted for safety and emailed our
trademark folks for some input. Sadly I received none and the advert
idea died.

I would be in favour of a new logo that we can use freely.

Duncan

[1] http://markmail.org/message/jgs4ucfmu2orlcia
[2] 
http://meta.stackoverflow.com/questions/260377/open-source-advertising-sidebar-2h-2014


 The log4j2 project did a very successful logo contest where they collected
 ideas for a new logo and finally picked the best proposal [1].

 How about we start our own logo contest for commons?

 Regards,
 Benedikt

 [1] https://issues.apache.org/jira/browse/LOG4J2-316



 -
 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] Any objections to LANG-1012?

[Duncan Jones]

Hi,

Does anyone have any objections to me implementing
https://issues.apache.org/jira/browse/LANG-1012? The goal is to
introduce:

  Validate.isFalse()
  Validate.largerThan() // isLargerThan() ??
  Validate.smallerThan() // isSmallerThan() ??

The isFalse() is just the natural counterpart to isTrue(), much like
JUnit added assertFalse(). The other two methods are slightly neater
ways of expressing x = y or x = y type constraints. Without
these, one either writes:

  Validate.isTrue(x = y);

or

  Validate.inclusiveBetween(y, Long.MAX_VALUE, x);

Neither of which is as concise as it could be.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Any objections to LANG-1012?

[Duncan Jones]

On 14 May 2014 00:04, Gary Gregory garydgreg...@gmail.com wrote:
 IMO toes does not belong in lang. It's too much like the bean validation 
 framework. It has potential to leak into a giant pile of methods with support 
 for all doors of objects and data types.

 Providing what java 7 has in Objects should be the limit, more or less.

 Gary


Maybe we should move in the other direction then. In 4.0 we could
strip some of the more specific methods and focus on a small handful,
all throwing IAE (subject to a consensus in the other thread).

Several comments on the classic (now outdated) blog post comparing
guava and lang [1] support that:

I find the commons validation methods a bit too specific, they
somehow reminds me of the countless PHP functions, duplicating
functionality only for the sake of beeing case insensitive.

Many of the methods in the Apache Commons Validate class are
unnecessary and distracting… it’s a problem I have with all of the
Apache Commons stuff I’ve looked at in comparison to Guava. There are
just too many methods that aren’t really needed. Guava boils things
down to the essentials.

Perhaps, like guava, we should be returning the tested object too.

Duncan


[1] 
http://piotrjagielski.com/blog/google-guava-vs-apache-commons-for-argument-validation/

 div Original message /divdivFrom: Duncan Jones 
 djo...@apache.org /divdivDate:05/13/2014  16:06  (GMT-05:00) 
 /divdivTo: Commons Developers List dev@commons.apache.org 
 /divdivSubject: [lang] Any objections to LANG-1012? /divdiv
 /divHi,

 Does anyone have any objections to me implementing
 https://issues.apache.org/jira/browse/LANG-1012? The goal is to
 introduce:

   Validate.isFalse()
   Validate.largerThan() // isLargerThan() ??
   Validate.smallerThan() // isSmallerThan() ??

 The isFalse() is just the natural counterpart to isTrue(), much like
 JUnit added assertFalse(). The other two methods are slightly neater
 ways of expressing x = y or x = y type constraints. Without
 these, one either writes:

   Validate.isTrue(x = y);

 or

   Validate.inclusiveBetween(y, Long.MAX_VALUE, x);

 Neither of which is as concise as it could be.

 Duncan

 -
 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: [lang]

[Duncan Jones]

On 13 May 2014 02:02, Phil Steitz phil.ste...@gmail.com wrote:


 On May 6, 2014, at 10:51 PM, Duncan Jones dun...@wortharead.com wrote:

 On 7 May 2014 01:52, Paul Benedict pbened...@apache.org wrote:

 When you dereference a null pointer, you get an NPE. We can agree to that.
 We can also agree it's not inherently wrong to throw IAE on a null
 argument
 check, but this discussion has never been about that. The discussion has
 always centered on what the trend setters are doing -- and they say go
 with
 NPE.

 Oracle/Sun throws NPE in its method:
 http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull%28T%29

 Google Guava throws NPE in its method:
 http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html#checkNotNull%28T%29

 It's pretty clear where industry is going and not using NPE is not
 expected. We shouldn't try to resist where all the thought leaders in our
 industry are going. It doesn't make any sense. No matter what personal
 affinity/preference you have towards IAE, it's a losing battle because the
 march is going the other direction.

 This is a very compelling point. We don't want to alienate our user base
 because a handful of us believe the Java community is going in the wrong
 direction.

 I could be swayed by that argument alone. We hardly need more reasons for
 people to consider Lang to be outdated compared with Guava etc.

 Interesting how I see that argument as exactly the opposite - ie if the only 
 argument in support of a technical decision is that's where things are 
 going I see that as a good reason not to capitulate.  The best thing about 
 OSS (at least how we have traditionally done it here @apache) is we make 
 technical decisions based on technical arguments and the people who actually 
 contribute to the code get listened to.  So instead of vague references to 
 thought leaders or what others are doing, what matters is what arguments 
 are presented here.  In this thread, I have yet to see a good argument for 
 tossing npe when an API advertises parm checking.  Do you have one?  Does 
 anyone else?

I have no technical arguments to present - IAE is the only sensible
technical option. I quite like your opinion that we should pave the
way with what we think is correct behaviour. I'm firmly back in the
IAE camp, I think.

On a similar subject, I note that the Validate.validIndex() methods
throw IndexOutOfBoundsException. I see this as the same argument as
NPE - we should throw IAE instead, since IOOBE is similarly a
something went wrong exception, rather than a validation exception.

Duncan




 Phil


 Paul


 Cheers,
 Paul


 On Tue, May 6, 2014 at 6:27 PM, sebb seb...@gmail.com wrote:

 On 6 May 2014 22:54, Paul Benedict pbened...@apache.org wrote:
 This is not a matter of law. If Oracle/Sun set a direction on how to
 use
 NPE, it's a really good idea to follow them -- even if you don't
 agree,
 do
 it for the sake of consistency. I don't think using IAE is somehow
 better
 Java than what they are doing. And I give weight to what Joshua said
 because he's a former architect of that company. Lang3 was designed to
 throw NPE on invalid null arguments because that's what the gurus,
 like
 he,
 in our industry who publish best practices say it should. If your
 opinion
 bears greater weight than those set forth the best practices, then you
 win,
 but I don't advocate going back to IAE for nulls for the reasons
 stated.

 The problem is still that NPE can be thrown by the JVM for code bugs.
 If you Google/Bing for what does NPE mean? most of the postings say
 that this is due to a bug in the code that throws it rather than a bug
 in the code that calls it.

 There is nothing inherently wrong with using IAE for reporting a null
 argument.
 I think it was a mistake to suggest using NPE for that.
 One might as well throw ArithmeticException for a zero argument that
 is going to be used as a divisor.
 Neither is as helpful as IAE.

 The problem is that NPE is ambiguous. IAE is not.




 Cheers,
 Paul


 On Tue, May 6, 2014 at 4:40 PM, Duncan Jones dun...@wortharead.com
 wrote:

 On 6 May 2014 22:27, Michael Osipov 1983-01...@gmx.net wrote:

 Am 2014-05-06 15:27, schrieb Benedikt Ritter:

 Hi Thiago,


 2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com:

 Hello people,

 Analizing the JIRA issue
 https://issues.apache.org/jira/browse/LANG-1008the
 contributors noticed that NumberUtils.max/min methods all have
 the
 same
 problem:
 They all throw an IllegalArgumentException when according to the
 official
 documentation (Oracle|Sun) says that a NullPointerException must
 be
 thrown
 when an argument must not be null.

 This is not a problem imho. It is a question of API design. I
 don't
 now
 an
 offical documentation that say when IAE or NPE _must_ be thrown.
 Sun/Oracle
 at some point decided to throw NPE when ever a null reference is
 passed
 to
 a method that doesn't accept null inputs. I

Re: Re: [lang]

[Duncan Jones]

On 7 May 2014 21:07, sebb seb...@gmail.com wrote:

 On 7 May 2014 01:51, Paul Benedict pbened...@apache.org wrote:
  When you dereference a null pointer, you get an NPE. We can agree to
that.
  We can also agree it's not inherently wrong to throw IAE on a null
argument
  check, but this discussion has never been about that. The discussion has
  always centered on what the trend setters are doing -- and they say go
with
  NPE.
 
  Oracle/Sun throws NPE in its method:
 
http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull%28T%29
 
  Google Guava throws NPE in its method:
 
http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html#checkNotNull%28T%29
 
  It's pretty clear where industry is going and not using NPE is not
  expected. We shouldn't try to resist where all the thought leaders in
our
  industry are going. It doesn't make any sense. No matter what personal
  affinity/preference you have towards IAE, it's a losing battle because
the
  march is going the other direction.

 None of that alters the fact the using NPE in this way is ambiguous.
 Whereas IAE is not.

Yes but is this a discussion about what is correct or what we should do in
Lang?

I think the two are not necessarily the same (sadly) and that the focus is
on the latter. Hence Paul's comment has merit.


  Paul
 
 
  Cheers,
  Paul
 
 
  On Tue, May 6, 2014 at 6:27 PM, sebb seb...@gmail.com wrote:
 
  On 6 May 2014 22:54, Paul Benedict pbened...@apache.org wrote:
   This is not a matter of law. If Oracle/Sun set a direction on how to
use
   NPE, it's a really good idea to follow them -- even if you don't
agree,
  do
   it for the sake of consistency. I don't think using IAE is somehow
  better
   Java than what they are doing. And I give weight to what Joshua said
   because he's a former architect of that company. Lang3 was designed
to
   throw NPE on invalid null arguments because that's what the gurus,
like
  he,
   in our industry who publish best practices say it should. If your
  opinion
   bears greater weight than those set forth the best practices, then
you
  win,
   but I don't advocate going back to IAE for nulls for the reasons
stated.
 
  The problem is still that NPE can be thrown by the JVM for code bugs.
  If you Google/Bing for what does NPE mean? most of the postings say
  that this is due to a bug in the code that throws it rather than a bug
  in the code that calls it.
 
  There is nothing inherently wrong with using IAE for reporting a null
  argument.
  I think it was a mistake to suggest using NPE for that.
  One might as well throw ArithmeticException for a zero argument that
  is going to be used as a divisor.
  Neither is as helpful as IAE.
 
  The problem is that NPE is ambiguous. IAE is not.
 
  
  
  
   Cheers,
   Paul
  
  
   On Tue, May 6, 2014 at 4:40 PM, Duncan Jones dun...@wortharead.com
  wrote:
  
   On 6 May 2014 22:27, Michael Osipov 1983-01...@gmx.net wrote:
   
Am 2014-05-06 15:27, schrieb Benedikt Ritter:
   
Hi Thiago,
   
   
2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com:
   
Hello people,
   
Analizing the JIRA issue
   https://issues.apache.org/jira/browse/LANG-1008the
contributors noticed that NumberUtils.max/min methods all have
the
  same
problem:
They all throw an IllegalArgumentException when according to the
   official
documentation (Oracle|Sun) says that a NullPointerException
must be
   thrown
when an argument must not be null.
   
   
This is not a problem imho. It is a question of API design. I
don't
  now
   an
offical documentation that say when IAE or NPE _must_ be thrown.
   Sun/Oracle
at some point decided to throw NPE when ever a null reference is
  passed
   to
a method that doesn't accept null inputs. I don't feel this is
right,
   since
a null input is also an illegal argument. Why make a
differenciation?
   IMHO
NPE should be reserved to the JVM, when a method is called on a
null
reference, but that's just my opinion.
   
   
It *is* a problem because NullPointerException and
   IllegalArgumentException have concrete semantics layed out in the
JDK's
   Javadocs. If you see how both are used in the JDK, you see that NPE
and
  IAE
   are used properly and there is no such restriction to the JDK only.
If
  you
   aread Effective Java, you'll see that you *have to* use NPE if a
null
   argument is passed. One might remember the NullArgumentException
back in
   Lang 2, it was removed because it is imperative to use NPE instead.
  
   Effective Java is a great book, but don't confuse Joshua's advice
with
  law.
  
   
Moreover, the Lang 3 package includes a great class, Validate,
which
  does
   things right and now I can ask, why the hell is that not used
throughout
   the entire library?
  
   +1 to this. We should update all of lang to use Validate once we've
  nailed
   this issue.
  
   Duncan

Re: Re: [lang]

[Duncan Jones]

On 7 May 2014 01:52, Paul Benedict pbened...@apache.org wrote:

 When you dereference a null pointer, you get an NPE. We can agree to that.
 We can also agree it's not inherently wrong to throw IAE on a null
argument
 check, but this discussion has never been about that. The discussion has
 always centered on what the trend setters are doing -- and they say go
with
 NPE.

 Oracle/Sun throws NPE in its method:

http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull%28T%29

 Google Guava throws NPE in its method:

http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html#checkNotNull%28T%29

 It's pretty clear where industry is going and not using NPE is not
 expected. We shouldn't try to resist where all the thought leaders in our
 industry are going. It doesn't make any sense. No matter what personal
 affinity/preference you have towards IAE, it's a losing battle because the
 march is going the other direction.

This is a very compelling point. We don't want to alienate our user base
because a handful of us believe the Java community is going in the wrong
direction.

I could be swayed by that argument alone. We hardly need more reasons for
people to consider Lang to be outdated compared with Guava etc.


 Paul


 Cheers,
 Paul


 On Tue, May 6, 2014 at 6:27 PM, sebb seb...@gmail.com wrote:

  On 6 May 2014 22:54, Paul Benedict pbened...@apache.org wrote:
   This is not a matter of law. If Oracle/Sun set a direction on how to
use
   NPE, it's a really good idea to follow them -- even if you don't
agree,
  do
   it for the sake of consistency. I don't think using IAE is somehow
  better
   Java than what they are doing. And I give weight to what Joshua said
   because he's a former architect of that company. Lang3 was designed to
   throw NPE on invalid null arguments because that's what the gurus,
like
  he,
   in our industry who publish best practices say it should. If your
  opinion
   bears greater weight than those set forth the best practices, then you
  win,
   but I don't advocate going back to IAE for nulls for the reasons
stated.
 
  The problem is still that NPE can be thrown by the JVM for code bugs.
  If you Google/Bing for what does NPE mean? most of the postings say
  that this is due to a bug in the code that throws it rather than a bug
  in the code that calls it.
 
  There is nothing inherently wrong with using IAE for reporting a null
  argument.
  I think it was a mistake to suggest using NPE for that.
  One might as well throw ArithmeticException for a zero argument that
  is going to be used as a divisor.
  Neither is as helpful as IAE.
 
  The problem is that NPE is ambiguous. IAE is not.
 
  
  
  
   Cheers,
   Paul
  
  
   On Tue, May 6, 2014 at 4:40 PM, Duncan Jones dun...@wortharead.com
  wrote:
  
   On 6 May 2014 22:27, Michael Osipov 1983-01...@gmx.net wrote:
   
Am 2014-05-06 15:27, schrieb Benedikt Ritter:
   
Hi Thiago,
   
   
2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com:
   
Hello people,
   
Analizing the JIRA issue
   https://issues.apache.org/jira/browse/LANG-1008the
contributors noticed that NumberUtils.max/min methods all have
the
  same
problem:
They all throw an IllegalArgumentException when according to the
   official
documentation (Oracle|Sun) says that a NullPointerException must
be
   thrown
when an argument must not be null.
   
   
This is not a problem imho. It is a question of API design. I
don't
  now
   an
offical documentation that say when IAE or NPE _must_ be thrown.
   Sun/Oracle
at some point decided to throw NPE when ever a null reference is
  passed
   to
a method that doesn't accept null inputs. I don't feel this is
right,
   since
a null input is also an illegal argument. Why make a
differenciation?
   IMHO
NPE should be reserved to the JVM, when a method is called on a
null
reference, but that's just my opinion.
   
   
It *is* a problem because NullPointerException and
   IllegalArgumentException have concrete semantics layed out in the
JDK's
   Javadocs. If you see how both are used in the JDK, you see that NPE
and
  IAE
   are used properly and there is no such restriction to the JDK only.
If
  you
   aread Effective Java, you'll see that you *have to* use NPE if a null
   argument is passed. One might remember the NullArgumentException
back in
   Lang 2, it was removed because it is imperative to use NPE instead.
  
   Effective Java is a great book, but don't confuse Joshua's advice
with
  law.
  
   
Moreover, the Lang 3 package includes a great class, Validate,
which
  does
   things right and now I can ask, why the hell is that not used
throughout
   the entire library?
  
   +1 to this. We should update all of lang to use Validate once we've
  nailed
   this issue.
  
   Duncan
  
   
   
However according to Apache Commons Lang Developer Guide, these
  methods

Re: [lang]

[Duncan Jones]

On 6 May 2014 19:19, Paul Benedict pbened...@apache.org wrote:
 NPE is implicit if the method does not allow an argument to be null. This
 doesn't have to be the case. This has nothing to do with the JDK vs. 3rd
 party source. It's just about the contract. As long as you document which
 arguments can be null, then you're good -- otherwise throw an NPE to
 capture the contract violation.


 Cheers,
 Paul

I'm strongly in favour of IAE for incorrect null inputs. It makes it
completely clear that the input was validated and found to be lacking.
A NPE tends to make me think something unanticipated has happened.

I agree with Sebb: NPEs will have people blaming the library before
their own code.

Duncan




 On Tue, May 6, 2014 at 12:09 PM, sebb seb...@gmail.com wrote:

 On 6 May 2014 14:27, Benedikt Ritter brit...@apache.org wrote:
  Hi Thiago,
 
 
  2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com:
 
  Hello people,
 
  Analizing the JIRA issue
 https://issues.apache.org/jira/browse/LANG-1008the
  contributors noticed that NumberUtils.max/min methods all have the same
  problem:
  They all throw an IllegalArgumentException when according to the
 official
  documentation (Oracle|Sun) says that a NullPointerException must be
 thrown
  when an argument must not be null.
 
 
  This is not a problem imho. It is a question of API design.

 +1

  I don't now an
  offical documentation that say when IAE or NPE _must_ be thrown.
 Sun/Oracle
  at some point decided to throw NPE when ever a null reference is passed
 to
  a method that doesn't accept null inputs. I don't feel this is right,
 since
  a null input is also an illegal argument. Why make a differenciation?
 IMHO
  NPE should be reserved to the JVM, when a method is called on a null
  reference, but that's just my opinion.
 

 +1.

 NPE used to mean a bug had occurred rather than the user had provided bad
 input.

 Using NPE for a parameter that must not be null confuses things.

 
 
  However according to Apache Commons Lang Developer Guide, these methods
 are
  all correct. This guide says that When throwing an exception to
 indicate a
  bad argument, always try to throw IllegalArgumentException, even if the
  argument was null. Do not throw NullPointerException..
 
 
  Since [lang] is currently designed this way, I'd rather deal with this
  issue for 4.0. We can then revisit our initial decision to only throw IAE
  an maybe align it to what the JDK now does. If you want to file an issue,
  my opinion is, that it should be fix version 4.0. Changing the exceptions
  that are thrown now may break clients (although I think there are very
 few
  use cases where one should catch IAE or NPE).

 If Commons ever decide to switch to NPE (I hope not) then it is
 imperative that the message is 100% clear that the problem is with  a
 method argument, and which argument is at fault.

 Otherwise we will likely find ourselves fielding bug reports about
 Commons code when it is the caller that is at fault.
 Even then, I suspect some reporters will just see the NPE and assume
 that the Commons code has a bug.

 If an argument is invalid, throw IAE.
 IMO it does not make sense to throw NPE for some invalid arguments and
 not others.
 What Sun/Oracle perhaps should have done was introduce an
 InvalidNullArgumentException

 The Javadoc (1.7) says:

 
 Thrown when an application attempts to use null in a case where an
 object is required. These include:

 Calling the instance method of a null object.
 Accessing or modifying the field of a null object.
 Taking the length of null as if it were an array.
 Accessing or modifying the slots of null as if it were an array.
 Throwing null as if it were a Throwable value.

 Applications should throw instances of this class to indicate other
 illegal uses of the null object.
 

 I suppose illegal use of the null object could be taken to mean
 passing null to a non-nullable parameter, but I think that is
 stretching it too far.

 
 
  This mail was sent in order to discuss around and make decisions to
 solve
  this dilemma where the Java official specification says X and the Apache
  official specification says Y.
 
 
  Can you please provide a lnk to the official specification you're
 refering
  to? ;-)
 
  Regards,
  Benedikt
 
 
 
  My sincere thanks for your time and consideration,
 
  --
  Thiago Andrade
 
 
 
 
  --
  http://people.apache.org/~britter/
  http://www.systemoutprintln.de/
  http://twitter.com/BenediktRitter
  http://github.com/britter

 -
 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: [lang]

[Duncan Jones]

On 6 May 2014 20:41, Phil Steitz phil.ste...@gmail.com wrote:
 On 5/6/14, 10:09 AM, sebb wrote:
 On 6 May 2014 14:27, Benedikt Ritter brit...@apache.org wrote:
 Hi Thiago,


 2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com:

 Hello people,

 Analizing the JIRA issue https://issues.apache.org/jira/browse/LANG-1008the
 contributors noticed that NumberUtils.max/min methods all have the same
 problem:
 They all throw an IllegalArgumentException when according to the official
 documentation (Oracle|Sun) says that a NullPointerException must be thrown
 when an argument must not be null.

 This is not a problem imho. It is a question of API design.
 +1

 I don't now an
 offical documentation that say when IAE or NPE _must_ be thrown. Sun/Oracle
 at some point decided to throw NPE when ever a null reference is passed to
 a method that doesn't accept null inputs. I don't feel this is right, since
 a null input is also an illegal argument. Why make a differenciation? IMHO
 NPE should be reserved to the JVM, when a method is called on a null
 reference, but that's just my opinion.

 +1.

 NPE used to mean a bug had occurred rather than the user had provided bad 
 input.

 Using NPE for a parameter that must not be null confuses things.

 However according to Apache Commons Lang Developer Guide, these methods are
 all correct. This guide says that When throwing an exception to indicate a
 bad argument, always try to throw IllegalArgumentException, even if the
 argument was null. Do not throw NullPointerException..

 Since [lang] is currently designed this way, I'd rather deal with this
 issue for 4.0. We can then revisit our initial decision to only throw IAE
 an maybe align it to what the JDK now does. If you want to file an issue,
 my opinion is, that it should be fix version 4.0. Changing the exceptions
 that are thrown now may break clients (although I think there are very few
 use cases where one should catch IAE or NPE).
 If Commons ever decide to switch to NPE (I hope not) then it is
 imperative that the message is 100% clear that the problem is with  a
 method argument, and which argument is at fault.

 Otherwise we will likely find ourselves fielding bug reports about
 Commons code when it is the caller that is at fault.
 Even then, I suspect some reporters will just see the NPE and assume
 that the Commons code has a bug.

 If an argument is invalid, throw IAE.
 IMO it does not make sense to throw NPE for some invalid arguments and
 not others.
 What Sun/Oracle perhaps should have done was introduce an
 InvalidNullArgumentException

 The Javadoc (1.7) says:

 Thrown when an application attempts to use null in a case where an
 object is required. These include:

 Calling the instance method of a null object.
 Accessing or modifying the field of a null object.
 Taking the length of null as if it were an array.
 Accessing or modifying the slots of null as if it were an array.
 Throwing null as if it were a Throwable value.

 Applications should throw instances of this class to indicate other
 illegal uses of the null object.
 

 I suppose illegal use of the null object could be taken to mean
 passing null to a non-nullable parameter, but I think that is
 stretching it too far.

 +1 to everything above.  The illegal use of the null object bit is
 an unfortunate choice of words as it seems to have opened the door
 to the s/IAE/NPE debate.  I am OK with throw NPE early when you
 know it is going to happen further down approach when API doc does
 not specify behavior, but I prefer APIs that document their
 preconditions clearly and throw IAE when actual parameters violate
 those preconditions.

 Phil

If consensus continues to be in the direction of IAE, do we consider
changing the behaviour of Validate.notNull() in 4.0? This currently
throws a NPE.

Duncan



 This mail was sent in order to discuss around and make decisions to solve
 this dilemma where the Java official specification says X and the Apache
 official specification says Y.

 Can you please provide a lnk to the official specification you're refering
 to? ;-)

 Regards,
 Benedikt


 My sincere thanks for your time and consideration,

 --
 Thiago Andrade



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter
 -
 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: Re: [lang]

[Duncan Jones]

On 6 May 2014 22:27, Michael Osipov 1983-01...@gmx.net wrote:

 Am 2014-05-06 15:27, schrieb Benedikt Ritter:

 Hi Thiago,


 2014-05-06 14:53 GMT+02:00 Thiago Andrade thia...@gmail.com:

 Hello people,

 Analizing the JIRA issue
https://issues.apache.org/jira/browse/LANG-1008the
 contributors noticed that NumberUtils.max/min methods all have the same
 problem:
 They all throw an IllegalArgumentException when according to the
official
 documentation (Oracle|Sun) says that a NullPointerException must be
thrown
 when an argument must not be null.


 This is not a problem imho. It is a question of API design. I don't now
an
 offical documentation that say when IAE or NPE _must_ be thrown.
Sun/Oracle
 at some point decided to throw NPE when ever a null reference is passed
to
 a method that doesn't accept null inputs. I don't feel this is right,
since
 a null input is also an illegal argument. Why make a differenciation?
IMHO
 NPE should be reserved to the JVM, when a method is called on a null
 reference, but that's just my opinion.


 It *is* a problem because NullPointerException and
IllegalArgumentException have concrete semantics layed out in the JDK's
Javadocs. If you see how both are used in the JDK, you see that NPE and IAE
are used properly and there is no such restriction to the JDK only. If you
aread Effective Java, you'll see that you *have to* use NPE if a null
argument is passed. One might remember the NullArgumentException back in
Lang 2, it was removed because it is imperative to use NPE instead.

Effective Java is a great book, but don't confuse Joshua's advice with law.


 Moreover, the Lang 3 package includes a great class, Validate, which does
things right and now I can ask, why the hell is that not used throughout
the entire library?

+1 to this. We should update all of lang to use Validate once we've nailed
this issue.

Duncan



 However according to Apache Commons Lang Developer Guide, these methods
are
 all correct. This guide says that When throwing an exception to
indicate a
 bad argument, always try to throw IllegalArgumentException, even if the
 argument was null. Do not throw NullPointerException..


 Correct to the dev guide only -- not Java.


 Since [lang] is currently designed this way, I'd rather deal with this
 issue for 4.0. We can then revisit our initial decision to only throw IAE
 an maybe align it to what the JDK now does. If you want to file an issue,
 my opinion is, that it should be fix version 4.0. Changing the exceptions
 that are thrown now may break clients (although I think there are very
few
 use cases where one should catch IAE or NPE).


 4.0 has to use Validate throughout the entire package. NPE and IAE
indicate a programming error in the client not adhering to the contract
depicted by the Javadocs, so it is the client's problem to deal with them.
With proper programming, you should not have to catch those exception at
all.


 This mail was sent in order to discuss around and make decisions to
solve
 this dilemma where the Java official specification says X and the Apache
 official specification says Y.


 Can you please provide a lnk to the official specification you're
refering
 to? ;-)


 Read Effective Java on exceptions. Thiago provided a URL in the JIRA
issue.

 Further good resources:

 1.
http://docs.oracle.com/javase/7/docs/api/java/lang/NullPointerException.html
 2.
http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html:
One case where it is common practice to throw a RuntimeException is when
the user calls a method incorrectly. For example, a method can check if one
of its arguments is incorrectly null. If an argument is null, the method
might throw a NullPointerException, which is an unchecked exception.

 Michael



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1588859 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java

[Duncan Jones]

On 25 April 2014 08:45, Benedikt Ritter brit...@apache.org wrote:
 Nice! But you seem to have auto-formating enabled, which leads to unrelated
 changes (see below). For larger changes you should enabled auto-formating
 only for edited lines or make a separate reformat commit.

 Regards,
 Benedikt

Thanks for the heads up. This was my first commit after moving from
Eclipse to IntelliJ, so clearly it's doing things I wasn't expecting.
Time to do battle with the settings...

Duncan



 2014-04-21 10:37 GMT+02:00 djo...@apache.org:

 Author: djones
 Date: Mon Apr 21 08:37:46 2014
 New Revision: 1588859

 URL: http://svn.apache.org/r1588859
 Log:
 Use enhanced for loop

 Modified:

 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java

 Modified:
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
 URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java?rev=1588859r1=1588858r2=1588859view=diff

 ==
 ---
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
 (original)
 +++
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
 Mon Apr 21 08:37:46 2014
 @@ -416,9 +416,7 @@ public class DurationFormatUtils {
  long milliseconds, final boolean padWithZeros) {
  final StringBuilder buffer = new StringBuilder();
  boolean lastOutputSeconds = false;
 -final int sz = tokens.length;
 -for (int i = 0; i  sz; i++) {
 -final Token token = tokens[i];
 +for (final Token token : tokens) {
  final Object value = token.getValue();
  final int count = token.getCount();
  if (value instanceof StringBuilder) {
 @@ -443,7 +441,7 @@ public class DurationFormatUtils {
  buffer.append(paddedValue(seconds, padWithZeros,
 count));
  lastOutputSeconds = true;
  } else if (value == S) {
 -if (lastOutputSeconds) {
 +if (lastOutputSeconds) {


 This looks unrelated


  // ensure at least 3 digits are displayed even if
 padding is not selected
  int width = padWithZeros ? Math.max(3, count) : 3;
  buffer.append(paddedValue(milliseconds, true,
 width));
 @@ -572,9 +570,8 @@ public class DurationFormatUtils {
   * @return boolean codetrue/code if contained
   */
  static boolean containsTokenWithValue(final Token[] tokens, final
 Object value) {
 -final int sz = tokens.length;
 -for (int i = 0; i  sz; i++) {
 -if (tokens[i].getValue() == value) {
 +for (Token token : tokens) {
 +if (token.getValue() == value) {
  return true;
  }
  }





 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependency resolution.

[Duncan Jones]

Hi Paul,

On 22 April 2014 15:25, Paul Benedict pbened...@apache.org wrote:
 Yup. I have depend on Lang 3 for my own code and many of my transitive
 dependencies relies on Lang 2. There's no problem with having both
 libraries in your code.

I haven't fully understood your description of the problem. You say
you've got commons-confguration:commons-configuration:1.9 on your
classpath and this requires commons-lang(2), yet you also acknowledge
that it's ok to have both commons-lang and commons-lang3 in your
classpath. I agree this shouldn't be a problem.

The exception you've shown looks more like something isn't happy with
the version of commons-configuration you're using; I'm not sure how
that relates to [lang]. Also, NoClassDefFoundError is typically thrown
*after* a previous failed attempt to find a class [1] - perhaps there
are more useful stack-traces elsewhere in your logs?

Can you perhaps provide another example of how things are breaking?

Duncan


[1] http://stackoverflow.com/a/5756989/474189



 On Tue, Apr 22, 2014 at 9:22 AM, Matt Benson gudnabr...@gmail.com wrote:

 Note that you can use [lang] v2 and v3 together in the same project as both
 the Maven coordinates and package names have been changed with the major
 version upgrade.

 Matt


 On Tue, Apr 22, 2014 at 9:07 AM, Petar Tahchiev paranoia...@gmail.com
 wrote:

  Hi guys,
 
  I found out I'm using quite a lot of the commons-*:commons-* artifacts in
  my project so I decided to upgrade them to their new version in
  org.apache.commons:whatever. I only upgraded those that I could so now I
  have for instance org.apache.commons:commons-lang3 in my classpath, but
  unfortunately I also have commons-confguration:commons-configuration:1.9
  and there I get exceptions like these:
 
  Caused by: java.lang.NoClassDefFoundError:
  org/apache/commons/configuration/ConfigurationException
  at java.lang.Class.getDeclaredMethods0(Native Method)
  at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
  at java.lang.Class.getDeclaredMethods(Class.java:1845)
  at
 
 
 org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findPersistenceMetadata(PersistenceAnnotationBeanPostProcessor.java:402)
  at
 
 
 org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessMergedBeanDefinition(PersistenceAnnotationBeanPostProcessor.java:332)
  at
 
 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyMergedBeanDefinitionPostProcessors(AbstractAutowireCapableBeanFactory.java:908)
  at
 
 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:512)
  at
 
 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
  at
 
 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
  at
 
 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
 
 
  So because commons-configuration:commons-configuration requires
  commons-lang2 as a dependency I'm forced to downgrade to commons-lang2.
 
  My request is this: is it possible to upgrade ALL the commons artifacts
 to
  the correct repository groupId (org.apache.commons) and upgrade their
  dependencies? Most of them are already there, and those which are not
 will
  most certainly benefit from a new release (i guess there's been quite a
  while they haven't been released and there might be some resolved issues
 in
  the JIRA).
 
  Is there anyone against having a new release on: commons-logging,
  commons-fileupload, commons-codec,
  commons-configuration,commons-beanutils,commons-digester and the rest of
  the projects which are still using the incorrect groupId.
 
  --
  Regards, Petar!
  Karlovo, Bulgaria.
  ---
  Public PGP Key at:
 
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
  Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
 




 --
 Cheers,
 Paul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Dependency resolution.

[Duncan Jones]

On 22 April 2014 15:45, Duncan Jones dun...@wortharead.com wrote:
 Hi Paul,

 On 22 April 2014 15:25, Paul Benedict pbened...@apache.org wrote:
 Yup. I have depend on Lang 3 for my own code and many of my transitive
 dependencies relies on Lang 2. There's no problem with having both
 libraries in your code.

 I haven't fully understood your description of the problem. You say
 you've got commons-confguration:commons-configuration:1.9 on your
 classpath and this requires commons-lang(2), yet you also acknowledge
 that it's ok to have both commons-lang and commons-lang3 in your
 classpath. I agree this shouldn't be a problem.

Apparently I'm confusing my Pauls with my Petars. My comments about
not understanding the exception (below) still stand, but the first
paragraph (above) can be ignored!


 The exception you've shown looks more like something isn't happy with
 the version of commons-configuration you're using; I'm not sure how
 that relates to [lang]. Also, NoClassDefFoundError is typically thrown
 *after* a previous failed attempt to find a class [1] - perhaps there
 are more useful stack-traces elsewhere in your logs?

 Can you perhaps provide another example of how things are breaking?

 Duncan


 [1] http://stackoverflow.com/a/5756989/474189



 On Tue, Apr 22, 2014 at 9:22 AM, Matt Benson gudnabr...@gmail.com wrote:

 Note that you can use [lang] v2 and v3 together in the same project as both
 the Maven coordinates and package names have been changed with the major
 version upgrade.

 Matt


 On Tue, Apr 22, 2014 at 9:07 AM, Petar Tahchiev paranoia...@gmail.com
 wrote:

  Hi guys,
 
  I found out I'm using quite a lot of the commons-*:commons-* artifacts in
  my project so I decided to upgrade them to their new version in
  org.apache.commons:whatever. I only upgraded those that I could so now I
  have for instance org.apache.commons:commons-lang3 in my classpath, but
  unfortunately I also have commons-confguration:commons-configuration:1.9
  and there I get exceptions like these:
 
  Caused by: java.lang.NoClassDefFoundError:
  org/apache/commons/configuration/ConfigurationException
  at java.lang.Class.getDeclaredMethods0(Native Method)
  at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
  at java.lang.Class.getDeclaredMethods(Class.java:1845)
  at
 
 
 org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findPersistenceMetadata(PersistenceAnnotationBeanPostProcessor.java:402)
  at
 
 
 org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessMergedBeanDefinition(PersistenceAnnotationBeanPostProcessor.java:332)
  at
 
 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyMergedBeanDefinitionPostProcessors(AbstractAutowireCapableBeanFactory.java:908)
  at
 
 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:512)
  at
 
 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
  at
 
 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
  at
 
 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
 
 
  So because commons-configuration:commons-configuration requires
  commons-lang2 as a dependency I'm forced to downgrade to commons-lang2.
 
  My request is this: is it possible to upgrade ALL the commons artifacts
 to
  the correct repository groupId (org.apache.commons) and upgrade their
  dependencies? Most of them are already there, and those which are not
 will
  most certainly benefit from a new release (i guess there's been quite a
  while they haven't been released and there might be some resolved issues
 in
  the JIRA).
 
  Is there anyone against having a new release on: commons-logging,
  commons-fileupload, commons-codec,
  commons-configuration,commons-beanutils,commons-digester and the rest of
  the projects which are still using the incorrect groupId.
 
  --
  Regards, Petar!
  Karlovo, Bulgaria.
  ---
  Public PGP Key at:
 
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
  Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
 




 --
 Cheers,
 Paul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Rationale for multiplying by one in Conversion?

[Duncan Jones]

Hi everyone,

The Conversion class has numerous instances in which a value is
multiplied by one (e.g. line 1054):

shift = i * 1 + dstPos;

I suspect this is a copy/paste issue, since other parts of the class
follow a similar pattern, e.g. line 881:

shift = i * 8 + dstPos;

The unit tests pass with these multiplications removed. Can anyone
suggest a reason to keep them? I'm loathe to remove something so odd
in case it has a reason for being there...

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Releasing 3.3.2

[Duncan Jones]

On 3 April 2014 07:39, Benedikt Ritter brit...@apache.org wrote:
 Hi all,

 we have discussed this before. Thanks to Niall, all the JavaDoc issues are
 now resolved, so I'm hoping to find the time this weekend to roll out an
 RC.

 There is one issue that we could consider for inclusion: LANG-990 - Avoid
 String allocation in StrBuilder.append(CharSequence) [1]. This looks like a
 nice improvement, so I'd like to include it. I've suggested to make some
 performance measurments, but I won't have the time to do them myself. I'd
 like to hear your opinion: do we need to measure the acutal performance
 improvment or can we include it, because it looks like an improvement and
 doesn't break anything?

Perhaps I'm overly cautious, but as LANG-990 is a performance tweak
and not a bug fix, I'd prefer to see it subjected to some minimal
performance testing before we include it. Although I agree the
improvements seem fairly self-evident to the eye. I was intending to
take the lead on that testing, but sadly I've not found time yet to
tackle it.

I would propose you cut the release without LANG-990, unless someone
has time to put some metrics together. I suggested the patch author
might do this to speed up the commit process [1], but so far he's not
taken up the challenge.

Duncan

[1] https://issues.apache.org/jira/browse/LANG-990?focusedCommentId=13954637



 Benedikt

 [1] https://issues.apache.org/jira/browse/LANG-990


 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1577332 - in /commons/proper/lang/trunk/src: changes/changes.xml main/java/org/apache/commons/lang3/time/DateUtils.java test/java/org/apache/commons/lang3/time/DateUtilsFragmentTest.j

[Duncan Jones]

On 15 Mar 2014 10:27, Benedikt Ritter brit...@apache.org wrote:

 2014-03-15 11:25 GMT+01:00 Benedikt Ritter brit...@apache.org:

  I guess this one was introduced by me when I tried to fix LANG-951 :-)
 

 The reporter doesn't seem to be amused... Does this call for a quit bug
fix
 release? I could prepare a RC today.

Might be a good idea. There's not really a work-around available.

Duncan



 
 
  2014-03-13 22:40 GMT+01:00 djo...@apache.org:
 
  Author: djones
  Date: Thu Mar 13 21:40:26 2014
  New Revision: 1577332
 
  URL: http://svn.apache.org/r1577332
  Log:
  LANG-987: DateUtils.getFragmentInDays(Date, Calendar.MONTH) returns
wrong
  days, reported by Jay Xu.
 
  Modified:
  commons/proper/lang/trunk/src/changes/changes.xml
 
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java
 
 
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsFragmentTest.java
 
  Modified: commons/proper/lang/trunk/src/changes/changes.xml
  URL:
 
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1577332r1=1577331r2=1577332view=diff
 
 
==
  --- commons/proper/lang/trunk/src/changes/changes.xml [utf-8]
(original)
  +++ commons/proper/lang/trunk/src/changes/changes.xml [utf-8] Thu Mar
13
  21:40:26 2014
  @@ -22,6 +22,7 @@
 body
 
 release version=3.4 date=TBA description=TBA
  +action issue=LANG-987 type=fix
  dev=djonesDateUtils.getFragmentInDays(Date, Calendar.MONTH) returns
  wrong days/action
   action issue=LANG-983 type=fix dev=sebbDurationFormatUtils
  does not describe format string fully/action
   action issue=LANG-981 type=fix
  dev=sebbDurationFormatUtils#lexx does not detect unmatched quote
  char/action
   action issue=LANG-984 type=fix dev=sebbDurationFormatUtils
  does not handle large durations correctly/action
 
  Modified:
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java
  URL:
 
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java?rev=1577332r1=1577331r2=1577332view=diff
 
 
==
  ---
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java
  (original)
  +++
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java
  Thu Mar 13 21:40:26 2014
  @@ -1690,13 +1690,15 @@ public class DateUtils {
   final long millisPerUnit = getMillisPerUnit(unit);
   long result = 0;
 
  +int offset = (unit == Calendar.DAY_OF_YEAR) ? 0 : 1;
  +
   // Fragments bigger than a day require a breakdown to days
   switch (fragment) {
   case Calendar.YEAR:
  -result += ((calendar.get(Calendar.DAY_OF_YEAR) -1) *
  MILLIS_PER_DAY) / millisPerUnit;
  +result += ((calendar.get(Calendar.DAY_OF_YEAR) -
offset)
  * MILLIS_PER_DAY) / millisPerUnit;
   break;
   case Calendar.MONTH:
  -result += ((calendar.get(Calendar.DAY_OF_MONTH) -1) *
  MILLIS_PER_DAY) / millisPerUnit;
  +result += ((calendar.get(Calendar.DAY_OF_MONTH) -
  offset) * MILLIS_PER_DAY) / millisPerUnit;
   break;
   default:
   break;
 
  Modified:
 
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsFragmentTest.java
  URL:
 
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsFragmentTest.java?rev=1577332r1=1577331r2=1577332view=diff
 
 
==
  ---
 
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsFragmentTest.java
  (original)
  +++
 
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsFragmentTest.java
  Thu Mar 13 21:40:26 2014
  @@ -561,4 +561,32 @@ testResult);
   / DateUtils.MILLIS_PER_HOUR,
   testResult);
   }
  +
  +@Test
  +public void testDaysOfMonthWithCalendar() throws Exception {
  +final long testResult = DateUtils.getFragmentInDays(aCalendar,
  Calendar.MONTH);
  +assertEquals(days, testResult);
  +}
  +
  +@Test
  +public void testDaysOfMonthWithDate() throws Exception {
  +final long testResult = DateUtils.getFragmentInDays(aDate,
  Calendar.MONTH);
  +final Calendar cal = Calendar.getInstance();
  +cal.setTime(aDate);
  +assertEquals(cal.get(Calendar.DAY_OF_MONTH), testResult);
  +}
  +
  +@Test
  +public void testDaysOfYearWithCalendar() throws Exception {
  +final long testResult = DateUtils.getFragmentInDays(aCalendar,
  Calendar.YEAR);
  +assertEquals(aCalendar.get(Calendar.DAY_OF_YEAR), 

Re: svn commit: r1568612 - in /commons/proper/lang/trunk/src: changes/ main/java/org/apache/commons/lang3/ main/java/org/apache/commons/lang3/text/translate/ test/java/org/apache/commons/lang3/

[Duncan Jones]

On 15 February 2014 10:35,  brit...@apache.org wrote:
 Author: britter
 Date: Sat Feb 15 10:35:35 2014
 New Revision: 1568612

 URL: http://svn.apache.org/r1568612
 Log:
 LANG-977: NumericEntityEscaper incorrectly encodes supplementary characters. 
 Thanks to Chris Karcher.


Chris isn't listed as a contributor in the POM file. Should we add him
or is the due-to field replacing the need for that?

- Duncan




 Modified:
 commons/proper/lang/trunk/src/changes/changes.xml
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringEscapeUtilsTest.java

 Modified: commons/proper/lang/trunk/src/changes/changes.xml
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1568612r1=1568611r2=1568612view=diff
 ==
 --- commons/proper/lang/trunk/src/changes/changes.xml [utf-8] (original)
 +++ commons/proper/lang/trunk/src/changes/changes.xml [utf-8] Sat Feb 15 
 10:35:35 2014
 @@ -22,6 +22,7 @@
body

release version=3.3 date=TBA description=Bugfix and Feature release
 +action issue=LANG-977 type=fix dev=britter due-to=Chris 
 KarcherNumericEntityEscaper incorrectly encodes supplementary 
 characters/action
  action issue=LANG-973 type=fix dev=sebbMake some private fields 
 final/action
  action issue=LANG-971 type=fix 
 dev=sebbNumberUtils#isNumber(String) fails to reject invalid Octal 
 numbers/action
  action issue=LANG-972 type=fix dev=sebbNumberUtils#isNumber does 
 not allow for hex 0XABCD/action

 Modified: 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java?rev=1568612r1=1568611r2=1568612view=diff
 ==
 --- 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
  (original)
 +++ 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
  Sat Feb 15 10:35:35 2014
 @@ -185,7 +185,7 @@ public class StringEscapeUtils {
  out.write(StringUtils.replace(input.toString(), 
 CSV_QUOTE_STR, CSV_QUOTE_STR + CSV_QUOTE_STR));
  out.write(CSV_QUOTE);
  }
 -return input.length();
 +return Character.codePointCount(input, 0, input.length());
  }
  }

 @@ -314,7 +314,7 @@ public class StringEscapeUtils {

  if ( input.charAt(0) != CSV_QUOTE || input.charAt(input.length() 
 - 1) != CSV_QUOTE ) {
  out.write(input.toString());
 -return input.length();
 +return Character.codePointCount(input, 0, input.length());
  }

  // strip quotes
 @@ -326,7 +326,7 @@ public class StringEscapeUtils {
  } else {
  out.write(input.toString());
  }
 -return input.length();
 +return Character.codePointCount(input, 0, input.length());
  }
  }


 Modified: 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java?rev=1568612r1=1568611r2=1568612view=diff
 ==
 --- 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
  (original)
 +++ 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
  Sat Feb 15 10:35:35 2014
 @@ -89,10 +89,10 @@ public abstract class CharSequenceTransl
  pos+= c.length;
  continue;
  }
 -//  // contract with translators is that they have to understand 
 codepoints
 -//  // and they just took care of a surrogate pair
 +// contract with translators is that they have to understand 
 codepoints
 +// and they just took care of a surrogate pair
  for (int pt = 0; pt  consumed; pt++) {
 -pos += Character.charCount(Character.codePointAt(input, pt));
 +pos += Character.charCount(Character.codePointAt(input, 
 pos));
  }
  }
  }

 Modified: 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringEscapeUtilsTest.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringEscapeUtilsTest.java?rev=1568612r1=1568611r2=1568612view=diff
 

Re: svn commit: r1568612 - in /commons/proper/lang/trunk/src: changes/ main/java/org/apache/commons/lang3/ main/java/org/apache/commons/lang3/text/translate/ test/java/org/apache/commons/lang3/

[Duncan Jones]

On 18 February 2014 15:58, Benedikt Ritter brit...@apache.org wrote:
 2014-02-18 16:28 GMT+01:00 Duncan Jones djo...@apache.org:

 On 15 February 2014 10:35,  brit...@apache.org wrote:
  Author: britter
  Date: Sat Feb 15 10:35:35 2014
  New Revision: 1568612
 
  URL: http://svn.apache.org/r1568612
  Log:
  LANG-977: NumericEntityEscaper incorrectly encodes supplementary
 characters. Thanks to Chris Karcher.


 Chris isn't listed as a contributor in the POM file. Should we add him
 or is the due-to field replacing the need for that?


 Well there are no absolute rules about this. But in this case we could add
 him, I guess. I'll take care of this.

 Thanks!

Ah, ok. I wasn't sure whether a single committed patch equated to
being a contributor.

In your eyes, when should I add someone to the POM file? I like the
idea of doing it relatively easily, since it's quite pleasing to see
one's name listed as a contributor, but I don't want to fly in the
face of what's normal on the project.


 - Duncan



 
  Modified:
  commons/proper/lang/trunk/src/changes/changes.xml
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringEscapeUtilsTest.java
 
  Modified: commons/proper/lang/trunk/src/changes/changes.xml
  URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1568612r1=1568611r2=1568612view=diff
 
 ==
  --- commons/proper/lang/trunk/src/changes/changes.xml [utf-8] (original)
  +++ commons/proper/lang/trunk/src/changes/changes.xml [utf-8] Sat Feb 15
 10:35:35 2014
  @@ -22,6 +22,7 @@
 body
 
 release version=3.3 date=TBA description=Bugfix and Feature
 release
  +action issue=LANG-977 type=fix dev=britter due-to=Chris
 KarcherNumericEntityEscaper incorrectly encodes supplementary
 characters/action
   action issue=LANG-973 type=fix dev=sebbMake some private
 fields final/action
   action issue=LANG-971 type=fix
 dev=sebbNumberUtils#isNumber(String) fails to reject invalid Octal
 numbers/action
   action issue=LANG-972 type=fix dev=sebbNumberUtils#isNumber
 does not allow for hex 0XABCD/action
 
  Modified:
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
  URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java?rev=1568612r1=1568611r2=1568612view=diff
 
 ==
  ---
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
 (original)
  +++
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
 Sat Feb 15 10:35:35 2014
  @@ -185,7 +185,7 @@ public class StringEscapeUtils {
   out.write(StringUtils.replace(input.toString(),
 CSV_QUOTE_STR, CSV_QUOTE_STR + CSV_QUOTE_STR));
   out.write(CSV_QUOTE);
   }
  -return input.length();
  +return Character.codePointCount(input, 0, input.length());
   }
   }
 
  @@ -314,7 +314,7 @@ public class StringEscapeUtils {
 
   if ( input.charAt(0) != CSV_QUOTE ||
 input.charAt(input.length() - 1) != CSV_QUOTE ) {
   out.write(input.toString());
  -return input.length();
  +return Character.codePointCount(input, 0,
 input.length());
   }
 
   // strip quotes
  @@ -326,7 +326,7 @@ public class StringEscapeUtils {
   } else {
   out.write(input.toString());
   }
  -return input.length();
  +return Character.codePointCount(input, 0, input.length());
   }
   }
 
 
  Modified:
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
  URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java?rev=1568612r1=1568611r2=1568612view=diff
 
 ==
  ---
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
 (original)
  +++
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/text/translate/CharSequenceTranslator.java
 Sat Feb 15 10:35:35 2014
  @@ -89,10 +89,10 @@ public abstract class CharSequenceTransl
   pos+= c.length;
   continue;
   }
  -//  // contract with translators is that they have to
 understand codepoints
  -//  // and they just took care of a surrogate pair
  +// contract with translators is that they have

Re: [LANG] Towards 3.3

[Duncan Jones]

On 31 January 2014 07:54, Benedikt Ritter brit...@apache.org wrote:
 Nice discussion. Thanks for clearing this up. So Duncan: go ahead if you
 got the time.

Hi Benedikt,

Based on other discussions on the ML, the fix for LANG-341 belongs in
the Conversion class. I think this warrants a larger piece of work to
implement some of the missing methods in that class. I therefore
suggest that LANG-341 should be ignored for 3.3 and shouldn't hold up
your plans to release.

Duncan




 2014/1/31 Duncan Jones dun...@wortharead.com

 On 31 January 2014 04:37, Henri Yandell flame...@gmail.com wrote:
  Read section 5 of the license.

 Ok, that's pretty clear-cut then. To save others from dragging up the
 wording:

 5. Submission of Contributions. Unless You explicitly state
 otherwise, any Contribution intentionally submitted for inclusion in
 the Work by You to the Licensor shall be under the terms and
 conditions of this License, without any additional terms or
 conditions.

 So I'd say any patch to existing source would be covered by that. The
 term Contribution is defined higher in the license and includes
 submission to the issue tracking system.

 Obtaining an ICLA should still be a goal, I think, but it shouldn't
 prevent us from adding useful patches to the project.

 Duncan



   On Jan 30, 2014 10:16 AM, Benedikt Ritter brit...@apache.org wrote:
 
  I'm not sure whether providing a patch for an AL licensed file is
  automatically licensed under AL as well. In the end the raw diff file
 does
  not contain the AL header, so you're better of with an ICLA.
 
  Benedikt
 
 
  2014/1/27 Henri Yandell flame...@gmail.com
 
   Depends whose arguing probably :)
  
   Our license gives us a right to contributions under Apache 2.0 unless
   stated otherwise; the ICLA is playing safer. We can also simply take
   anything under a compatible license and include (with suitable
  licensing).
   I did that for a method from Spring.
  
   Hen
  
  
   On Sun, Jan 26, 2014 at 1:31 PM, Duncan Jones dun...@wortharead.com
   wrote:
  
On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com
 wrote:
 On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org
  wrote:
 Hi Duncan,


 2014/1/26 Duncan Jones dun...@wortharead.com

 On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org
   wrote:
  Hi all,
 
  we've fixed some bugs and we have some nice new features
   implemented
  (DiffBuilder, Jaro-Winkler Distance, RandomUtils,
  ClassPathUtils),
so I'm
  planning to cut a RC in the first week of February.
 
  I just wanted to know if there is anything you'd like to have
included in
  the next release. Then please tag it with fix version 3.3.
 
  Regards,
  Benedikt
 

 I'm debating whether LANG-341 might be a candidate for
 inclusion.
  The
 patch is fairly complete, just needs Javadocs and a couple of
 additional unit tests, which I can sort over the coming week.
 What
  do
 you guys think? It seems like a useful addition to me.


 Yes looks neat. The problem I'm seeing is, that the last
 activity is
from
 Nov 2011, and the contributor has no ICLA listed (see [1]), so
 IP is
   not
 absolutely clear. I'm unsure if we can use this contribution
 without
   the
 ICLA. Anyway, Hen has contributed the patch Vincent Ricard used,
 so
  we
can
 use Hen's patch and improve it.

 Benedikt

 [1] http://people.apache.org/committer-index.html#unlistedclas


 Good point. I think in this case I'll ping the contributor to get
 their thoughts on an ICLA and assume this will miss v3.3. He's
 done a
 lot of work to extend Hen's patch and it would be a shame for that
  not
 to get committed if he's interested. If there's no reply (or no
 interest), I'll sort something for v3.4.

   
Having said that... does this still represent a problem if the
contributor has patched existing code (containing the Apache
 license)?
   
Are there any situations where we can take a patch and apply it to
trunk without the contributor having an ICLA? I certainly had
 patches
applied in the past without an ICLA, but perhaps things were more
 lax
then?
   
   


 Duncan


  -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
   
   
  
 
 
 
  --
  http://people.apache.org/~britter/
  http

Re: svn commit: r1563259 - in /commons/proper/lang/trunk: pom.xml src/changes/changes.xml src/main/java/org/apache/commons/lang3/math/NumberUtils.java src/test/java/org/apache/commons/lang3/math/Numbe

[Duncan Jones]

On 31 January 2014 22:44, Jörg Schaible joerg.schai...@gmx.de wrote:

 -1

 Please revert, we have that already in org.apache.commons.lang3.Conversion

Thanks for pointing that out. I've reverted.

I agree it looks like Conversion might be a better place to put the
functionality. It seems what I've added is equivalent to (the not yet
implemented) Conversion.intToByteArrayBe(),
Conversion.byteArrayBeToInt() and so on. So perhaps to close LANG-341,
those methods will need to be implemented.

Any thoughts on the double/float methods included in LANG-341? I
wasn't 100% sure of those anyway, but they didn't hurt when being
added to NumberUtils. Is there a place for those in Conversion?

Duncan



 --- Weitergeleitete Nachricht (Anfang)

 Betreff: svn commit: r1563259 - in /commons/proper/lang/trunk: pom.xml
 src/changes/changes.xml
 src/main/java/org/apache/commons/lang3/math/NumberUtils.java
 src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java
 Absender: djones-1odqgaof3lkdnm+yrof...@public.gmane.org
 Datum: Fri, 31 Jan 2014 21:12:58 +
 Newsgruppe: gmane.comp.jakarta.commons.scm

 Author: djones
 Date: Fri Jan 31 21:12:57 2014
 New Revision: 1563259

 URL: http://svn.apache.org/r1563259
 Log:
 LANG-341: Please add number to byte[] methods. Suggested by Lilianne E. Blaze.
 Final patch from Vincent Ricard (with thanks to Henri Yandell).

 Modified:
 commons/proper/lang/trunk/pom.xml
 commons/proper/lang/trunk/src/changes/changes.xml
 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java
 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java

 Modified: commons/proper/lang/trunk/pom.xml
 URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/pom.xml?rev=1563259r1=1563258r2=1563259view=diff
 ==
 --- commons/proper/lang/trunk/pom.xml (original)
 +++ commons/proper/lang/trunk/pom.xml Fri Jan 31 21:12:57 2014
 @@ -365,6 +365,9 @@
nameTravis Reeder/name
  /contributor
  contributor
 +  nameVincent Ricard/name
 +/contributor
 +contributor
nameAntony Riley/name
  /contributor
  contributor

 Modified: commons/proper/lang/trunk/src/changes/changes.xml
 URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1563259r1=1563258r2=1563259view=diff
 ==
 --- commons/proper/lang/trunk/src/changes/changes.xml [utf-8] (original)
 +++ commons/proper/lang/trunk/src/changes/changes.xml [utf-8] Fri Jan 31
 21:12:57 2014
 @@ -22,6 +22,7 @@
body

release version=3.3 date=TBA description=Bugfix and Feature release
 +action issue=LANG-341 type=add due-to=Vincent Ricard
 dev=djonesPlease add number to byte[] methods/action
  action issue=LANG-961 type=update
 dev=ggregoryorg.apache.commons.lang3.reflect.FieldUtils.removeFinalModifier(Field)
 does not clean up after itself/action
  action issue=LANG-958 type=update dev=chasFastDateParser javadoc
 incorrectly states that SimpleDateFormat is used internally/action
  action issue=LANG-637 type=add dev=djonesThere should be a
 DifferenceBuilder with a ReflectionDifferenceBuilder implementation/action

 Modified:
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java
 URL:
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java?rev=1563259r1=1563258r2=1563259view=diff
 ==
 ---
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java
 (original)
 +++
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java
 Fri Jan 31 21:12:57 2014
 @@ -21,6 +21,7 @@ import java.math.BigDecimal;
  import java.math.BigInteger;

  import org.apache.commons.lang3.StringUtils;
 +import org.apache.commons.lang3.Validate;

  /**
   * pProvides extra functionality for Java Number classes./p
 @@ -1433,4 +1434,239 @@ public class NumberUtils {
  return !allowSigns  foundDigit;
  }

 +// NOTE: toPrimitive(byte[]) method contents are taken from:
 +//
 http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/DataInputStream.java
 +// toByteArray(primitive) method contents are taken from:
 +//
 http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/DataOutputStream.java
 +
 +
 +/**
 + * p
 + * Converts a byte array to a {@code short}.
 + * /p
 + * p
 + * The first two bytes of the
 + * array are converted from two's complement representation to a {@code
 short}.
 + * Any additional bytes are ignored.
 + * /p
 + * p
 + * If the array is {@code null}, {@code 0} is 

Re: [io] Addition of a TrailerInputStream class?

[Duncan Jones]

Hi Oliver,

On 29 January 2014 20:25, Oliver Heger oliver.he...@oliver-heger.de wrote:
 Hi Duncan,

 Am 28.01.2014 22:18, schrieb Duncan Jones:
 Hi all,

 For a project of mine I developed a class named TrailerInputStream,
 which reads from an InputStream whilst retaining a buffer of N bytes
 (the trailer), Once the stream has been exhausted, the final N bytes
 are obtained by calling the getTrailer() method.

 I found it helpful for reading structured data in which the main
 contents of the stream are processed differently to the trailer at the
 end.

 Is there a place for something like this in IO? I can imagine a
 symmetric class called HeaderInputStream as well.

 Current code is at
 https://github.com/RNCryptor/JNCryptor/blob/streaming/src/main/java/org/cryptonode/jncryptor/TrailerInputStream.java.
 It's not yet in a fit state for submission, but isn't far away in
 terms of comment quality and unit tests.

 looks useful. I once have written something similar as a contribution to
 Tika for extracting ID3 tags from an MP3 file. So I think, this would
 fit into [io].

Ok, great. I'll tidy up the code and add it to an issue for further
feedback from the IO crowd.

Duncan


 Oliver


 Kind regards,

 Duncan

 -
 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: [lang] RuntimeException types

[Duncan Jones]

On 30 Jan 2014 16:38, Matt Benson gudnabr...@gmail.com wrote:

 How do we feel about changing the type of a thrown RTE?  Specifically, we
 have agreed to standardize on the idea that Validate.notNull() throws
 NullPointerException, but the recently added
 FieldUtils#removeFinalModifier() method validates the incoming field
 parameter with Validate.isTrue(field != null), throwing
 IllegalArgumentException.  I prefer the simplicity of Validate.notNull()
 but changing this now would mean that consumers of the method who are
 conceivably now catching IllegalArgumentException would now fail to catch
 the thrown NPE.

 Thoughts?

 Matt

If this is the new normal, we should update the developer guide on the
website as it currently says the opposite.

Duncan

Re: [LANG] Towards 3.3

[Duncan Jones]

On 31 January 2014 04:37, Henri Yandell flame...@gmail.com wrote:
 Read section 5 of the license.

Ok, that's pretty clear-cut then. To save others from dragging up the wording:

5. Submission of Contributions. Unless You explicitly state
otherwise, any Contribution intentionally submitted for inclusion in
the Work by You to the Licensor shall be under the terms and
conditions of this License, without any additional terms or
conditions.

So I'd say any patch to existing source would be covered by that. The
term Contribution is defined higher in the license and includes
submission to the issue tracking system.

Obtaining an ICLA should still be a goal, I think, but it shouldn't
prevent us from adding useful patches to the project.

Duncan



  On Jan 30, 2014 10:16 AM, Benedikt Ritter brit...@apache.org wrote:

 I'm not sure whether providing a patch for an AL licensed file is
 automatically licensed under AL as well. In the end the raw diff file does
 not contain the AL header, so you're better of with an ICLA.

 Benedikt


 2014/1/27 Henri Yandell flame...@gmail.com

  Depends whose arguing probably :)
 
  Our license gives us a right to contributions under Apache 2.0 unless
  stated otherwise; the ICLA is playing safer. We can also simply take
  anything under a compatible license and include (with suitable
 licensing).
  I did that for a method from Spring.
 
  Hen
 
 
  On Sun, Jan 26, 2014 at 1:31 PM, Duncan Jones dun...@wortharead.com
  wrote:
 
   On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote:
On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org
 wrote:
Hi Duncan,
   
   
2014/1/26 Duncan Jones dun...@wortharead.com
   
On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org
  wrote:
 Hi all,

 we've fixed some bugs and we have some nice new features
  implemented
 (DiffBuilder, Jaro-Winkler Distance, RandomUtils,
 ClassPathUtils),
   so I'm
 planning to cut a RC in the first week of February.

 I just wanted to know if there is anything you'd like to have
   included in
 the next release. Then please tag it with fix version 3.3.

 Regards,
 Benedikt

   
I'm debating whether LANG-341 might be a candidate for inclusion.
 The
patch is fairly complete, just needs Javadocs and a couple of
additional unit tests, which I can sort over the coming week. What
 do
you guys think? It seems like a useful addition to me.
   
   
Yes looks neat. The problem I'm seeing is, that the last activity is
   from
Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is
  not
absolutely clear. I'm unsure if we can use this contribution without
  the
ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so
 we
   can
use Hen's patch and improve it.
   
Benedikt
   
[1] http://people.apache.org/committer-index.html#unlistedclas
   
   
Good point. I think in this case I'll ping the contributor to get
their thoughts on an ICLA and assume this will miss v3.3. He's done a
lot of work to extend Hen's patch and it would be a shame for that
 not
to get committed if he's interested. If there's no reply (or no
interest), I'll sort something for v3.4.
   
  
   Having said that... does this still represent a problem if the
   contributor has patched existing code (containing the Apache license)?
  
   Are there any situations where we can take a patch and apply it to
   trunk without the contributor having an ICLA? I certainly had patches
   applied in the past without an ICLA, but perhaps things were more lax
   then?
  
  
   
   
Duncan
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
   
   
   
   
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
  
 



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[io] Addition of a TrailerInputStream class?

[Duncan Jones]

Hi all,

For a project of mine I developed a class named TrailerInputStream,
which reads from an InputStream whilst retaining a buffer of N bytes
(the trailer), Once the stream has been exhausted, the final N bytes
are obtained by calling the getTrailer() method.

I found it helpful for reading structured data in which the main
contents of the stream are processed differently to the trailer at the
end.

Is there a place for something like this in IO? I can imagine a
symmetric class called HeaderInputStream as well.

Current code is at
https://github.com/RNCryptor/JNCryptor/blob/streaming/src/main/java/org/cryptonode/jncryptor/TrailerInputStream.java.
It's not yet in a fit state for submission, but isn't far away in
terms of comment quality and unit tests.

Kind regards,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Etiquette for clearing warnings

[Duncan Jones]

Hi,

Currently Eclipse is showing me 20 warnings for the lang code-base,
mostly unnecessary imports and unnecessary (or missing)
@SuppressWarnings statements.

Is it generally acceptable to file a commit that attempts to swot a
few (or all) of these in one go?

And perhaps more importantly, do other people see the same warnings
about @SuppressWarnings? I know these are compiler-specific, so
perhaps people not using Eclipse are not seeing these. Eclipse, for
example, doesn't accept

  @SuppressWarnings( Deprecation )

as the same as

  @SuppressWarnings(  deprecation )

and flags it as an unsupported annotation.

I don't want to irritate half the team by changing the code base to
suit my IDE, possibly creating further warnings for their own
preferred IDE. But equally I tend to try and keep any project
completely free of errors.

Advice welcome!

Kind regards,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Towards 3.3

[Duncan Jones]

On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote:
 Hi all,

 we've fixed some bugs and we have some nice new features implemented
 (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm
 planning to cut a RC in the first week of February.

 I just wanted to know if there is anything you'd like to have included in
 the next release. Then please tag it with fix version 3.3.

 Regards,
 Benedikt


I'm debating whether LANG-341 might be a candidate for inclusion. The
patch is fairly complete, just needs Javadocs and a couple of
additional unit tests, which I can sort over the coming week. What do
you guys think? It seems like a useful addition to me.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Towards 3.3

[Duncan Jones]

On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote:
 Hi Duncan,


 2014/1/26 Duncan Jones dun...@wortharead.com

 On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote:
  Hi all,
 
  we've fixed some bugs and we have some nice new features implemented
  (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm
  planning to cut a RC in the first week of February.
 
  I just wanted to know if there is anything you'd like to have included in
  the next release. Then please tag it with fix version 3.3.
 
  Regards,
  Benedikt
 

 I'm debating whether LANG-341 might be a candidate for inclusion. The
 patch is fairly complete, just needs Javadocs and a couple of
 additional unit tests, which I can sort over the coming week. What do
 you guys think? It seems like a useful addition to me.


 Yes looks neat. The problem I'm seeing is, that the last activity is from
 Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not
 absolutely clear. I'm unsure if we can use this contribution without the
 ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can
 use Hen's patch and improve it.

 Benedikt

 [1] http://people.apache.org/committer-index.html#unlistedclas


Good point. I think in this case I'll ping the contributor to get
their thoughts on an ICLA and assume this will miss v3.3. He's done a
lot of work to extend Hen's patch and it would be a shame for that not
to get committed if he's interested. If there's no reply (or no
interest), I'll sort something for v3.4.

Duncan



 Duncan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Towards 3.3

[Duncan Jones]

On 26 January 2014 19:47, Duncan Jones dun...@wortharead.com wrote:
 On 26 January 2014 18:49, Benedikt Ritter brit...@apache.org wrote:
 Hi Duncan,


 2014/1/26 Duncan Jones dun...@wortharead.com

 On 26 January 2014 13:33, Benedikt Ritter brit...@apache.org wrote:
  Hi all,
 
  we've fixed some bugs and we have some nice new features implemented
  (DiffBuilder, Jaro-Winkler Distance, RandomUtils, ClassPathUtils), so I'm
  planning to cut a RC in the first week of February.
 
  I just wanted to know if there is anything you'd like to have included in
  the next release. Then please tag it with fix version 3.3.
 
  Regards,
  Benedikt
 

 I'm debating whether LANG-341 might be a candidate for inclusion. The
 patch is fairly complete, just needs Javadocs and a couple of
 additional unit tests, which I can sort over the coming week. What do
 you guys think? It seems like a useful addition to me.


 Yes looks neat. The problem I'm seeing is, that the last activity is from
 Nov 2011, and the contributor has no ICLA listed (see [1]), so IP is not
 absolutely clear. I'm unsure if we can use this contribution without the
 ICLA. Anyway, Hen has contributed the patch Vincent Ricard used, so we can
 use Hen's patch and improve it.

 Benedikt

 [1] http://people.apache.org/committer-index.html#unlistedclas


 Good point. I think in this case I'll ping the contributor to get
 their thoughts on an ICLA and assume this will miss v3.3. He's done a
 lot of work to extend Hen's patch and it would be a shame for that not
 to get committed if he's interested. If there's no reply (or no
 interest), I'll sort something for v3.4.


Having said that... does this still represent a problem if the
contributor has patched existing code (containing the Apache license)?

Are there any situations where we can take a patch and apply it to
trunk without the contributor having an ICLA? I certainly had patches
applied in the past without an ICLA, but perhaps things were more lax
then?




 Duncan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Welcome Duncan Jones, committer

[Duncan Jones]

On 25 January 2014 08:51, Thomas Neidhart thomas.neidh...@gmail.com wrote:
 On 01/24/2014 04:20 PM, Gary Gregory wrote:
 Hi All,

 Please give a warm welcome to Duncan Jones, our latest committer.

 Welcome aboard Duncan!

 Well, you have been around for some time, but welcome as committer ;-)

 Thomas

I'm delighted to join as a committer, thank you everyone.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Handling of empty string in StringUtils

[Duncan Jones]

On 14 January 2014 11:17, Benedikt Ritter brit...@apache.org wrote:
 2014/1/13 Gary Gregory garydgreg...@gmail.com

 On Mon, Jan 13, 2014 at 12:45 PM, sebb seb...@gmail.com wrote:

  What does the Javadoc say?
 

 The Javadoc describes the current behavior, which is whacky IMO. This could
 be a case where the docs documents the code, even though it does not make
 sense.

 It sounds dangerous to change it in a minor release.


 There are at least two issues:

 1. StringUtils.spilt:

   StringUtils.split(null,ANY) = [ ]
   StringUtils.split(, ANY) = null

 2. Inconsistency bewteen containsNone and containsOnly (what I said before):

   StringUtils.containsOnly(, ANY) = StringUtils.containsNone(, ANY)
 = true
 All of this is documented in JavaDoc, which doesn't mean it is wrong.

 1) is just inconvinient. Changing it should not affect client code, since
 it will look like this:

 String[] parts = StringUtils.split(str, abc);
 if(party != null) {
// iterate over parts
 }

 Retruning an empty array will not affect this code.

Not that specific example, no. But it would certainly affect:

String[] parts = StringUtils.split(str, abc);
if(party == null) {
   // do something else
}

I don't think this can be changed in a minor release.

Duncan


 2) is a bug imho and needs to be fixed. The empty string at the same time
 contains anything and contains nothing (the latter is right). Bugs should
 be fixed in minor releases, even if the fix changes semantics of a method
 (from wrong to right). We can make this very clear in the release notes
 with an additional subscetion about this.

 Benedikt



 Gary



 
  On 13 January 2014 17:00, Benedikt Ritter brit...@apache.org wrote:
   ping, any thought on this?
  
  
   2014/1/11 Benedikt Ritter brit...@apache.org
  
   Hi,
  
   while looking through the open issues for lang, I came across
 LANG-823:
   StringUtils.split should handle empty strings the same as other
 content
   [1]. The request makes sense to me - the empty string should be
 handled
   like any other content.
  
   Then I looked into StringUtils to see how other methods handle the
 empty
   string and there are more examples of specific handling of the empty
   string. For example the following will return true:
  
  StringUtils.containsOnly(, abc)
  
   and it gets even more weird, since
  
  StringUtils.containsNone(, abc)
  
   also returns true! How can the same string a the same time _only_
  contain
   abc and contain none of abc?
  
   I can not see any reason for this behavior. Why is the empty string
   different from any other string content? I'd like to change the
  behavior of
   the affected methods, but wanted to get some feedback first.
  
   Benedikt
  
   [1] https://issues.apache.org/jira/browse/LANG-823
  
  
   --
   http://people.apache.org/~britter/
   http://www.systemoutprintln.de/
   http://twitter.com/BenediktRitter
   http://github.com/britter
  
  
  
  
   --
   http://people.apache.org/~britter/
   http://www.systemoutprintln.de/
   http://twitter.com/BenediktRitter
   http://github.com/britter
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 


 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Snap-shot version in website header

[Duncan Jones]

Hi all,

The top of the commons-lang web page reads:

Last Published: 01 January 2014  | Version: 3.3-SNAPSHOT 

Shouldn't that read:

Last Published: 01 January 2014  | Version: 3.2  ??

Or are we changing the site between releases, thus necessitating that
we build a site using the current (snapshot) version number?

Thanks,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Next steps

[Duncan Jones]

On 2 January 2014 14:40, Gary Gregory garydgreg...@gmail.com wrote:
 +1 to it all.

 Gary

  Original message 
 From: Benedikt Ritter brit...@apache.org
 Date:01/02/2014  05:29  (GMT-05:00)
 To: Commons Developers List dev@commons.apache.org
 Subject: [LANG] Next steps

 Hi all,

 I've successfully gone through my first release (wasn't as bad as I had
 expected it to be). I still have to do the Jira stuff, will do that tonight
 probably.
 So, here is what I have in mind for lang as next steps.

 Move User Guide from Website to package-info.java:
 The user guide is structured in terms of packages in lang. It looks like
 the package-info.java files are better suited for this kind of information.
 Since Lang isn't a framework where multiple parts play together, I don't
 see the need for a real user guide.

 Push out 3.2.1:
 Although the two issues identified by Oliver and Jörg didn't block release
 3.2, I'd like to push out a bugfix (probably containing the above changes)

 Move to git:
 We have talked about this a lot, and I had the feeling, that the people
 working on [lang] are fine with moving to git. I'm planning to work out a
 little guide on how to work on issues, create branches, create releases
 using git. But this will probably take a while.

 Thoughts?

 Benedikt
 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

Sounds great to me. I think we also need to focus on a faster release
cycle. The idea of release early, release often is regularly quoted
by people on the ML, yet it took us over two years to move from 3.1 to
3.2. It would be nice to see a smaller feature set in each release,
thus allowing for more regular releases.

Thanks for getting 3.2 out the door!

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Lang 3.2 based on RC1

[Duncan Jones]

On 23 Dec 2013 18:32, Matt Benson gudnabr...@gmail.com wrote:

 Bene pointed out to me that he did build w/ Java 7; of course the target
 setting in the POM is the reason the classfiles are Java 6 compatible,
 which is the important thing in any case.

Presumably that means the Javadocs have a Java 7 style? Is that a problem
or do we produce the website Javadocs in a different process?

Duncan


 Matt


 On Mon, Dec 23, 2013 at 11:00 AM, Matt Benson gudnabr...@gmail.com
wrote:

  - RAT report looks okay.
  - I successfully build the contents of the source artifacts with both
Java
  6 and Java 7
  - I successfully build the contents of the tag
  - britter code signing key is in
  https://dist.apache.org/repos/dist/release/commons/KEYS
  - All sigs and hashes check out
  - Binary jars appear to have been built using Java 6
  - All LICENSE and NOTICE files appear to be where they should
 
  +1 to release from me.
 
  Matt
 
 
  On Sun, Dec 22, 2013 at 5:11 AM, Benedikt Ritter brit...@apache.org
wrote:
 
  Hello All,
 
  We have fixed quite a few bugs and added some significant enhancements
  since Commons Lang 3.1 was released, so I would like to release Commons
  Lang 3.2.
 
  Commons Lang 3.2 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/lang/ (svn revision
  3964)
 
Maven artifacts are here:
 
 
 
https://repository.apache.org/content/repositories/orgapachecommons-014/org/apache/commons/commons-lang3/3.2/
 
Details of changes since 3.1 are in the release notes:
 
https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
 
 
 
http://people.apache.org/~britter/commons-lang3/3.2-RC1/site/changes-report.html
 
  The tag is here:
 
 
http://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_2_RC1/(svn
  1552978)
 
  Site:
http://people.apache.org/~britter/commons-lang3/3.2-RC1/site/
(note some *relative* links are broken and the 1.2 directories are
not
  yet created - these will be OK once the site is deployed.
Also note, that PMD shows a lot of warnings due to useless
parenthesis.
  We have decided to leave these in the code for readability.
Findbugs has a few warnings, none of which we consider to be
dangerous,
  but as always: patches are welcome ;-)
 
  Clirr Report (compared to 3.1):
 
 
 
http://people.apache.org/~britter/commons-lang3/3.2-RC1/site/clirr-report.html
(note that the Clirr report show 3 errors. This changes are
considered
  to
  be save for client code. More Information about this can be found in
the
  release notes)
 
  RAT Report:
 
 
 
http://people.apache.org/~britter/commons-lang3/3.2-RC1/site/rat-report.html
 
  KEYS:
http://www.apache.org/dist/commons/KEYS
 
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. after
  December 25 2013 at 12:30 CET
 
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
 
Thanks!
 
Benedikt
 
  --
  http://people.apache.org/~britter/
  http://www.systemoutprintln.de/
  http://twitter.com/BenediktRitter
  http://github.com/britter
 
 
 

Re: [ALL] Stack Overflow are offering free open source adverts - should we partake?

[Duncan Jones]

On 9 December 2013 11:48, Benedikt Ritter brit...@apache.org wrote:
 2013/12/9 Henri Yandell flame...@gmail.com

 On Sat, Dec 7, 2013 at 12:43 AM, Benedikt Ritter benerit...@gmail.com
 wrote:

 
 
  Send from my mobile device
 
   Am 06.12.2013 um 18:11 schrieb sebb seb...@gmail.com:
  
   On 6 December 2013 14:11, Duncan Jones djo...@cantab.net wrote:
   On 6 December 2013 12:51, Benedikt Ritter benerit...@gmail.com
  wrote:
   2013/12/6 Gilles gil...@harfang.homelinux.org
  
   Hi.
  
  
   On Fri, 6 Dec 2013 12:26:57 +, Duncan Jones wrote:
  
   Hi everyone,
  
   Stack Overflow allows open source projects to create a free advert
 to
   encourage participation in their project.
  
   This is certainly worth exploring.
  
  
   If you're willing to do this, go for it!
  
  
   Here's an effort I knocked up just now:  http://imgur.com/eTyqln6
  
   Any thoughts? Not sure how we should sell ourselves...
  
   That logo is for the ASF, not Commons.
   I don't think that it is permissible to use the logo in that way.
 
  Well, it's the logo we use on the top left side on commons.apache.org.
  I'd ask Legal for their opinion on this.
 
  
   I think this should be run past Trademarks and/or Press.
 

 Love the idea Duncan :)

 On the logo - if Commons can't use its logo without having to ask
 Trademarks/Press/Legal each time, then my non-binding opinion is that
 Commons needs a different logo. It's should be the Commons logo, not the
 ASF as a whole. If the feather + 'Commons' isn't enough to make it a
 Commons logo, Commons needs to dump the feather.


 I've thought about a new logo for commons for a while now. If only I could
 manage to invest some time to push the new commons site skin based on
 fluido forward. Would be nice to have a fresh new website and a new logo.
 Maybe we could host a contest, like they did for log4j [1].

 I'm really bad when it comes to photoshop and the like, but I'd like to
 have a logo where the letters of commons look like little puzzle pieces.

 Benedikt

 PS: Sorry for the off-topic noise :-)

 [1] https://issues.apache.org/jira/browse/LOG4J2-316


I think a logo contest would be a great idea. In the meantime, I've
emailed the trademark folks at ASF to get their thoughts/approval on
using the feather in the interim for my advert.

Stack Overflow forces projects to refresh their ads every six months,
so hopefully we'll have something in place by the time we would need
to renew this one.

Duncan




 This might, however, be highlighting that Commons brand is primarily the
 ASF's brand, unlike many other Apache projects :)

 Hen




 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ALL] Stack Overflow are offering free open source adverts - should we partake?

[Duncan Jones]

Hi everyone,

Stack Overflow allows open source projects to create a free advert to
encourage participation in their project. The rules are clearly
explained in the following post:
http://meta.stackoverflow.com/questions/210389/open-source-advertising-sidebar-1h-2014.

In summary, we create a 220x250 image that encourages participation in
Apache Commons. We then post it as an answer to that thread and it
will be served up automatically to Stack Overflow users (provided we
receive enough up-votes).

I'm happy to do this on behalf of Apache Commons, but I wanted feedback on:

 - Whether we want to do this?
 - Is there someone more talented who can do the image work?

Last time this advertising spree was organised
(http://meta.stackoverflow.com/questions/195823/open-source-advertising-sidebar-2h-2013)
there were only 8 participants. We should get in on this.

Kind regards,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Stack Overflow are offering free open source adverts - should we partake?

[Duncan Jones]

On 6 December 2013 12:51, Benedikt Ritter benerit...@gmail.com wrote:
 2013/12/6 Gilles gil...@harfang.homelinux.org

 Hi.


 On Fri, 6 Dec 2013 12:26:57 +, Duncan Jones wrote:

 Hi everyone,

 Stack Overflow allows open source projects to create a free advert to
 encourage participation in their project.


 This is certainly worth exploring.


 If you're willing to do this, go for it!


Here's an effort I knocked up just now:  http://imgur.com/eTyqln6

Any thoughts? Not sure how we should sell ourselves...




  The rules are clearly
 explained in the following post:

 http://meta.stackoverflow.com/questions/210389/open-source-
 advertising-sidebar-1h-2014.

 In summary, we create a 220x250 image that encourages participation in
 Apache Commons. We then post it as an answer to that thread and it
 will be served up automatically to Stack Overflow users (provided we
 receive enough up-votes).

 I'm happy to do this on behalf of Apache Commons, but I wanted feedback
 on:

  - Whether we want to do this?
  - Is there someone more talented who can do the image work?

 Last time this advertising spree was organised

 (http://meta.stackoverflow.com/questions/195823/open-
 source-advertising-sidebar-2h-2013)
 there were only 8 participants. We should get in on this.


 Another way to make the projects more visible is to edit Wikipedia entries
 that refer to implementations in various programming languages of the
 concept
 explained in the article.
 [I mentioned this some time ago, but there were zero comment about
 usefulness or
 feasibility (I don't know how easy it is to become a Wikipedia editor).]


 I think I've commented on this (or maybe I wanted to, but forgot it ;-). My
 thoughts on this: do it! :-) Anybody can edit wikipedia pages. You don't
 even need a user account for it. There are some exceptions to this rule,
 but I don't think the pages you have in mind fall into this category.




 Regards,
 Gilles



 -
 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: [lang] ImmutablePair is final

[Duncan Jones]

On 22 October 2013 21:07, Gary Gregory garydgreg...@gmail.com wrote:
 On Tue, Oct 22, 2013 at 3:59 PM, Matt Benson gudnabr...@gmail.com wrote:

 So what is having a non-generic runtime class accomplishing for you?


 The subclass is a kind of pair AND it is domain typed to my app.

 Gary

Sebb is correct - composition would work well here. You can still
defer to the equals/hashcode from the underlying ImmutablePair as you
appear to store no other state within the class.

Duncan





 Matt


 On Tue, Oct 22, 2013 at 2:29 PM, Gary Gregory garydgreg...@gmail.com
 wrote:

 
 
 
  Sent via the Samsung Galaxy Note® 3, an ATT 4G LTE smartphone
 
   Original message 
  From: sebb
  Date:10/22/2013 13:37 (GMT-05:00)
  To: Commons Developers List
  Subject: Re: [lang] ImmutablePair is final
 
  On 22 October 2013 18:33, Gary Gregory garydgreg...@gmail.com wrote:
   On Tue, Oct 22, 2013 at 1:22 PM, Paul Benedict pbened...@apache.org
  wrote:
  
   If you can subclass, the class will likely be mutable somehow
 (accessing
   protected or package-private data?) -- even introducing new variables
   exclusive to the subclass. The final keyword is used well here.
  
  
   Here is my use case for which I've cloned ImmutablePair into my own
  package
   (yuck):
 
  Composition (rather than extension) would work better here surely?
 
  Surely indeed Shirley ;) (Airplane!)
 
  Right now I am getting hashCode and equals for free with the subclass
  hack.
 
  Gary
 
 
   public final class ImmutableFooImmutableBarPair extends
   ImmutablePairImmutableFoo, ImmutableBar {
  
   private static final long serialVersionUID = 123L;
  
   public ImmutableFooImmutableBarPair (final ImmutableFoo foo, final
   ImmutableBar bar) {
   super(Validate.notNull(nameMatch), Validate.notNull(article));
   }
  
   public ImmutableFoo getImmutableFoo() {
   return this.getValue();
   }
  
   public ImmutableBar getImmutableBar() {
   return this.getKey();
   }
   ...
   ImmutableFooImmutableBarPair pair = new
  ImmutableFooImmutableBarPair(myFoo,
   myBar);
   ...
   pair.getImmutableFoo();
   ...
   pair.getImmutableBar();
  
   Gary
  
  
  
   On Tue, Oct 22, 2013 at 12:15 PM, sebb seb...@gmail.com wrote:
  
On 22 October 2013 18:10, Gary Gregory garydgreg...@gmail.com
  wrote:
 Hi All:

 Is there any reason we would want to keep ImmutablePair final?
   
To stop mutable subclasses from being created?
   
BTW, it's unfortunate that the fields are public; they should have
been private (there are public getters).
   
 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
   
   
  
  
   --
   Cheers,
   Paul
  
  
  
  
   --
   E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
   Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
   JUnit in Action, Second Edition http://www.manning.com/tahchiev/
   Spring Batch in Action http://www.manning.com/templier/
   Blog: http://garygregory.wordpress.com
   Home: http://garygregory.com/
   Tweet! http://twitter.com/GaryGregory
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Lang: ObjectUtils

[Duncan Jones]

On 4 July 2013 19:43, Rafael Santini raf...@santini.eti.br wrote:
 Hi,

 I would like to propose a method in ObjectUtils class that receives an array
 of objects and returns true if all objects are not null. I have implemented
 the following:

 public static boolean isNull(Object object) {
return object == null;
 }

 public static boolean isNotNull(Object object) {
return isNull(object) == false;
 }

 public static boolean isNotNull(Object... objects) {
for (Object object : objects) {
if (isNull(object)) {
return false;
}
}
return true;
 }

 Can I submit a patch for this feature?

To directly answer your question, patches should be submitted as an
enhancement request on the issue tracking system
(http://commons.apache.org/proper/commons-lang/issue-tracking.html).
Please include thorough unit tests in your patch.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Method to return random byte array?

[Duncan Jones]

On 15 June 2013 14:58, Duncan Jones dun...@wortharead.com wrote:
 On 14 June 2013 07:55, Duncan Jones dun...@wortharead.com wrote:
 On 13 June 2013 21:26, Phil Steitz wrote:
 On 6/13/13 1:03 AM, Duncan Jones wrote:
 snip

 I am not sure where this little method would fit in [lang]; but it might
 make sense to add there in the simple form above (with RANDOM
 static, I assume).

 Indeed, I had assumed any addition to [lang] would just use a standard
 source of randomness (i.e. a static Random or SecureRandom instance).
 However, I'm struggling to see an existing class that could
 accommodate the functionality and creating a new RandomUtils class
 feels a bit heavyweight, unless others can think of additional methods
 that would be useful.

 I gave it some further thought and realised there were some other
 methods that would prove useful in such a RandomUtils class. I've
 created https://issues.apache.org/jira/browse/LANG-900 and attached an
 implementation. I welcome comments.

In particular, I welcome comments on whether or not to constrain the
start and end range values to be non-negative.

In the current implementation (attached to the bug), I enforced
non-negative values, e.g. for `nextInt(X, Y)`, both X and Y must be
non-negative. This simplified the implementation because it meant that
Y - X couldn't be larger than the maximum value of an int. However,
this could be changed for nextInt with (untested) code such as:


public static int nextInt(int startInclusive, int endExclusive) {
Validate.isTrue(endExclusive = startInclusive,
Start value must be smaller or equal to end value.);

if (startInclusive == endExclusive) {
return startInclusive;
}

long range = endExclusive - startInclusive;
return (int) startInclusive + nextLong(0, range);
}


This may work for ints, but it gets more difficult for longs. Any
thoughts on this?

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Method to return random byte array?

[Duncan Jones]

On 14 June 2013 07:55, Duncan Jones dun...@wortharead.com wrote:
 On 13 June 2013 21:26, Phil Steitz wrote:
 On 6/13/13 1:03 AM, Duncan Jones wrote:
snip

 I am not sure where this little method would fit in [lang]; but it might
 make sense to add there in the simple form above (with RANDOM
 static, I assume).

 Indeed, I had assumed any addition to [lang] would just use a standard
 source of randomness (i.e. a static Random or SecureRandom instance).
 However, I'm struggling to see an existing class that could
 accommodate the functionality and creating a new RandomUtils class
 feels a bit heavyweight, unless others can think of additional methods
 that would be useful.

I gave it some further thought and realised there were some other
methods that would prove useful in such a RandomUtils class. I've
created https://issues.apache.org/jira/browse/LANG-900 and attached an
implementation. I welcome comments.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Method to return random byte array?

[Duncan Jones]

On 15 June 2013 15:49, Gary Gregory garydgreg...@gmail.com wrote:
 I thought 2.6 had such a class and we got rid of it.

2.6 had a class by the same name (so I've discovered since your mail),
but it merely amalgamated the different random methods from Math and
Random.

I think this new class does exactly what is required from Commons Lang
and adds functionality that is missing from the base classes.

Duncan



 On Sat, Jun 15, 2013 at 9:58 AM, Duncan Jones dun...@wortharead.com wrote:

 On 14 June 2013 07:55, Duncan Jones dun...@wortharead.com wrote:
  On 13 June 2013 21:26, Phil Steitz wrote:
  On 6/13/13 1:03 AM, Duncan Jones wrote:
 snip
 
  I am not sure where this little method would fit in [lang]; but it might
  make sense to add there in the simple form above (with RANDOM
  static, I assume).
 
  Indeed, I had assumed any addition to [lang] would just use a standard
  source of randomness (i.e. a static Random or SecureRandom instance).
  However, I'm struggling to see an existing class that could
  accommodate the functionality and creating a new RandomUtils class
  feels a bit heavyweight, unless others can think of additional methods
  that would be useful.

 I gave it some further thought and realised there were some other
 methods that would prove useful in such a RandomUtils class. I've
 created https://issues.apache.org/jira/browse/LANG-900 and attached an
 implementation. I welcome comments.

 Duncan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Method to return random byte array?

[Duncan Jones]

On 13 June 2013 21:26, Phil Steitz wrote:
 On 6/13/13 1:03 AM, Duncan Jones wrote:
 Hi,

 A piece of code I write far too often is:

 ==
 public static byte[] getRandomBytes(int length) {
   // validate length is non-negative

   byte[] result = new byte[length];
   RANDOM.nextBytes(result);
   return result;
 }
 ==

 Is there a place for something like this in Commons Lang? Or, better,
 does this already exist in another commons project?

 I would be +1 for adding this (modified to use the configured
 RandomGenerator) to the RandomDataGenerator class in
 o.a.c.math.random.  The advantage of adding it to there is that that
 class allows the underlying PRNG to be configured by the user.

That looks like a good place to put it. I'll submit a patch to that project.

 I am not sure where this little method would fit in [lang]; but it might
 make sense to add there in the simple form above (with RANDOM
 static, I assume).

Indeed, I had assumed any addition to [lang] would just use a standard
source of randomness (i.e. a static Random or SecureRandom instance).
However, I'm struggling to see an existing class that could
accommodate the functionality and creating a new RandomUtils class
feels a bit heavyweight, unless others can think of additional methods
that would be useful.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Method to return random byte array?

[Duncan Jones]

Hi,

A piece of code I write far too often is:

==
public static byte[] getRandomBytes(int length) {
  // validate length is non-negative

  byte[] result = new byte[length];
  RANDOM.nextBytes(result);
  return result;
}
==

Is there a place for something like this in Commons Lang? Or, better,
does this already exist in another commons project?

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[CLI] Option class may need some attention

[Duncan Jones]

Hi,

The Option class has some odd characteristics that I think should be addressed:

1. The class can be constructed with null values, either by using the
default builder constructor (discussed in CLI-224) or by passing null
values into the constructor. I think instead we should define the
minimum information required for a meaningful Option (short option and
description?) and enforce that the user passes these.

Without such a change, it's possible to produce nonsense options and
cause exceptions, e.g.

Option option = new Option(null, null);
option.getId(); // throws NullPointerException


In a similar vein, I think the new default constructor proposed for
the builder in CLI-224 should go.

2. The equals method only inspects the short and the long option. Even
if this is a good idea (and I'm quite convinced it isn't), it should
at least be documented. Otherwise, one can produce surprisingly
equal objects, such as:

Option option = new Option(null, foo);
Option option2 = new Option(null, bar);
assertNotEquals(option, option2); // Fails because objects are equal

Unless there is a good reason, the equals method should test all fields.

Any thoughts on this? Can we make such changes without breaking too
much backwards compatibility?

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CLI] Option class may need some attention

[Duncan Jones]

On 16 February 2013 20:53, Thomas Neidhart thomas.neidh...@gmail.com wrote:
 On 02/16/2013 03:04 PM, Duncan Jones wrote:
 Hi,

 The Option class has some odd characteristics that I think should be 
 addressed:

 1. The class can be constructed with null values, either by using the
 default builder constructor (discussed in CLI-224) or by passing null
 values into the constructor. I think instead we should define the
 minimum information required for a meaningful Option (short option and
 description?) and enforce that the user passes these.

 Without such a change, it's possible to produce nonsense options and
 cause exceptions, e.g.

 Option option = new Option(null, null);
 option.getId(); // throws NullPointerException


 In a similar vein, I think the new default constructor proposed for
 the builder in CLI-224 should go.

 I am fine to add additional sanity checks for nonsense input.

OK. I would suggest the short option is the only required parameter
(non-null, non-empty) - a description should be optional. What do you
say?


 2. The equals method only inspects the short and the long option. Even
 if this is a good idea (and I'm quite convinced it isn't), it should
 at least be documented. Otherwise, one can produce surprisingly
 equal objects, such as:

 Option option = new Option(null, foo);
 Option option2 = new Option(null, bar);
 assertNotEquals(option, option2); // Fails because objects are 
 equal

 Unless there is a good reason, the equals method should test all fields.

 Any thoughts on this? Can we make such changes without breaking too
 much backwards compatibility?

 The parser takes advantage of this wrt required options in some weird
 way which I honestly do not want to touch as it seems to work.

 The 1.x API has several flaws, and I am not sure if it is worth
 correcting them. My intention is to do a 1.3 release with several
 bugfixes / new features (like the new DefaultParser) and then move on to
 cli 2 which will hopefully fix these problems.

Ok, fair enough. Last year I was hunting for someone interested in
pursuing CLI 2.x, so let me know when you turn your attention there
and I'll help out.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

[Duncan Jones]

In this specific case, I think a ..., not null caveat is sufficient.
But in the general case, I think documenting interesting runtime
exceptions in the javadoc is good practice. Does the CheckStyle config
need tweaking?

On 8 February 2013 08:26, Benedikt Ritter brit...@apache.org wrote:
 Hi Simo,


 2013/2/8 Simone Tripodi simonetrip...@apache.org

  How do you feel about this? Checkstyle complains about this, and I think
 it
  is sufficient to tell users that an argument must not be null.

 sorry, which one?


 should have made that clearer :)
 I removed the @throws NullpointerException from the JavaDoc because check
 style complains about this (NPE is not declared in the method's signature).
 I think it is enough to tell users that an argument must not be null. WDYT?

 Benedikt



 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.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: [lang] Time for 3.2?

[Duncan Jones]

On 6 November 2012 02:02, Gary Gregory garydgreg...@gmail.com wrote:
 Hi All:

 I just committed a fix for [lang] and realized it's been a YEAR since 3.1!
 Wow, time flies.

 Are we ready for a release?

 Does anyone have anything they'd like to contribute?

 Gary

If anyone has the time to review it, I'd happily see the
DifferenceBuilder classes included in the release
(https://issues.apache.org/jira/browse/LANG-637).

I've also submitted a patch for
https://issues.apache.org/jira/browse/LANG-757, which handles HTML
escapes without semi-colons. Not sure if anyone has had a chance to
review that yet.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Some first steps to implementing LANG-637

[Duncan Jones]

On 1 October 2012 14:07, Duncan Jones dun...@wortharead.com wrote:
 I've now uploaded a complete solution for LANG-637 (see
 commons-lang3-LANG-637-complete.patch in JIRA) and I would very much
 appreciate feedback on the design and implementation. I've already
 factored in comments from James C and Matt B.

 I leant heavily on the existing reflection work in EqualsBuilder when
 adding the same functionality to my DiffBuilder class. If any part of
 my code particularly requires review, it is that area. Not just in the
 implementation details, but in some of the design decisions
 (particularly whether it is correct to throw a CastClassException when
 the types are not suited for comparison).

Just wondering if no feedback is good feedback? I've got plenty of
time to add some improvements if anyone has any pointers. I'd love to
see this make its way into the 3.2 release.

Thanks,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: JIRA bombs on ticket VFS-437

[Duncan Jones]

On 4 October 2012 14:08, Gary Gregory garydgreg...@gmail.com wrote:
 When I try to view https://issues.apache.org/jira/browse/VFS-437 I get:

 An error occurred whilst rendering this message. Please contact the
 administrators, and inform them of this bug. Details: ---
 snip

Yes, I get that too.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java

[Duncan Jones]

On 3 October 2012 18:24, Jörg Schaible joerg.schai...@gmx.de wrote:
 Matt Benson wrote:

 Urgh; I find these method names rather painful.  Why wouldn't we
 simply provide endianness and bit ordering as enums, and parameterize
 accordingly?

 Because the algorithm is different (although similar) every time and not all
 combinations are implemented?

 Honestly, we would have to use in most cases a switch/case statement
 internally anyway and either throw UnsupportedOperationException for the
 unimplemented cases or someone would have to implement it ... ;-)

I think the enum-based solution is much more elegant; the JavaDoc
could then contain a table demonstrating which combinations are
supported. The better of two evils, IMO.

I'm always in favour of methods that can be easily understood from a
cursory glance. It bodes well for easy code maintenance.

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org