commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Jones <djo...@apache.org>
Subject Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?
Date Sun, 19 Oct 2014 13:12:32 GMT
On 19 October 2014 07:04, Duncan Jones <djones@apache.org> wrote:
> On 18 October 2014 06:25, Duncan Jones <duncan@wortharead.com> wrote:
>> On 17 October 2014 23:41, James Sawle <jamessawle@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 <sebbaz@gmail.com> wrote:
>>>>
>>>>> On 17 October 2014 22:56, James Sawle <jamessawle@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 <djones@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 <git@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 <jamessawle@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 <jamessawle@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


Mime
View raw message