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...@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
