You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Duncan Jones <dj...@apache.org> on 2014/10/17 13:45:24 UTC
[lang] New compare() methods in LANG-536 pull request match Java
source - is this ok?
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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?
Posted by James Sawle <ja...@hotmail.com>.
I apologise for the spelling mistakes in the previous message. Need to remember not to send messages after drinks on a Friday :p
Sent from my iPhone
> On 17 Oct 2014, at 22:56, James Sawle <ja...@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.
>
> 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.
>
> Sent from my iPhone
>
>> On 17 Oct 2014, at 12:45, Duncan Jones <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>>> with INFRA.
>>> ---
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java
source - is this ok?
Posted by Duncan Jones <dj...@apache.org>.
On 19 October 2014 07:04, Duncan Jones <dj...@apache.org> wrote:
> On 18 October 2014 06:25, Duncan Jones <du...@wortharead.com> wrote:
>> On 17 October 2014 23:41, James Sawle <ja...@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 <se...@gmail.com> wrote:
>>>>
>>>>> On 17 October 2014 22:56, James Sawle <ja...@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 <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>>>>>>> with INFRA.
>>>>>>> ---
>>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java
source - is this ok?
Posted by Duncan Jones <dj...@apache.org>.
On 18 October 2014 06:25, Duncan Jones <du...@wortharead.com> wrote:
> On 17 October 2014 23:41, James Sawle <ja...@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 <se...@gmail.com> wrote:
>>>
>>>> On 17 October 2014 22:56, James Sawle <ja...@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 <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>>>>>> with INFRA.
>>>>>> ---
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java
source - is this ok?
Posted by Duncan Jones <du...@wortharead.com>.
On 17 October 2014 23:41, James Sawle <ja...@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 <se...@gmail.com> wrote:
>>
>>> On 17 October 2014 22:56, James Sawle <ja...@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 <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>>>>> with INFRA.
>>>>> ---
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?
Posted by James Sawle <ja...@hotmail.com>.
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.
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!
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.
Sent from my iPhone
> On 17 Oct 2014, at 23:25, sebb <se...@gmail.com> wrote:
>
>> On 17 October 2014 22:56, James Sawle <ja...@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 <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>>>> with INFRA.
>>>> ---
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java
source - is this ok?
Posted by sebb <se...@gmail.com>.
On 17 October 2014 22:56, James Sawle <ja...@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 <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>>> with INFRA.
>>> ---
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?
Posted by James Sawle <ja...@hotmail.com>.
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.
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.
Sent from my iPhone
> On 17 Oct 2014, at 12:45, Duncan Jones <dj...@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 <gi...@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 <ja...@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 <ja...@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 infrastructure@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org