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