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 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 >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
