On 8 June 2017 at 18:09, Gary Gregory <garydgreg...@gmail.com> wrote: > On Thu, Jun 8, 2017 at 9:57 AM, sebb <seb...@gmail.com> wrote: > >> On 8 June 2017 at 17:19, Gary Gregory <garydgreg...@gmail.com> wrote: >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <sesunc...@gmail.com> wrote: >> > >> >> [A Note, not a vote :) ] >> >> >> >> 1. Clirr is generally considered obsolete, as it hadn't been worked on >> for >> >> about ten years. japicmp is a good replacement, especially for report >> >> generation, and is used in other commons projects. >> >> >> > >> > IIRC, we've started using japicm here and there. Each component can >> decide. >> > But yes, Clirr looks pretty dead. >> > >> > >> >> 2. Are the "changes" to the values in CharEncoding really necessary[1] >> (The >> >> deprecation surely is). Technically this is a potentially breaking >> binary >> >> incompatible change, as constant strings and primitives are inlined at >> >> compile time. [2] >> >> In this particular case, the results of load-time evaluation of the new >> >> initialization expressions are identical to the old constants, so it's >> >> behaviourally compatible; however, since this is the case, and since >> it's >> >> all deprecated anyway, why not leave the old values in-place? >> >> >> > >> > The changes are not "necessary" that for sure and we do get Clirr >> warnings: >> > >> > Value of field ISO_8859_1 is no longer a compile-time constant >> > Value of field US_ASCII is no longer a compile-time constant >> > Value of field UTF_16 is no longer a compile-time constant >> > Value of field UTF_16BE is no longer a compile-time constant >> > Value of field UTF_16LE is no longer a compile-time constant >> > Value of field UTF_8 is no longer a compile-time constant >> > >> > It's source compatible. What is the issue at runtime that could hurt >> users? >> >> As the OP wrote, constants are inlined by the compiler. >> So unless all code is recompiled, if it referenced the constant it may >> have a stale value. >> That is not binary compatible. >> > > But in this case the actual values are the same are they not? So what is > the difference? Would this only be a problem if we changed the string > values?
AFAIK the compiler only inlines compile-time constants. So going forward, the values won't be inlined. I assume the behaviour will be unaffected since the runtime value should be the same as the constant. The release notes really ought to explain why the Clirr report items aren't a problem. > Which we can't since these are defined in the JRE. And the JRE is > unlikely to change those. > > Gary > > >> >> > >> >> 3. JDK9 adds some extra parameters to the Deprecated annotation (most >> >> notably forRemoval=true, which is used to indicate that the annotated >> item >> >> is really really deprecated.) It's not needed in this case, but is >> worth >> >> thinking about when jdk9 is eventually released (latest schedule >> change : >> >> from 7/27/2017 to 9/21/2017). >> >> >> > >> > I do not think we plan on making Java 9 a requirement for any current >> > project. >> > >> > Gary >> > >> > >> >> >> >> Simon >> >> >> >> [1] https://github.com/apache/commons-lang/commit/7c19a1ff4c217 >> >> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4baR48 >> >> >> >> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls- >> >> 13.html#jls-13.4.9 >> >> >> >> On Jun 8, 2017 4:48 AM, "Benedikt Ritter" <brit...@apache.org> wrote: >> >> >> >> > Hello, >> >> > >> >> > we have fixed quite a few bugs and added some nice new features since >> >> > Commons Lang 3.5 was released, so I would like to release Commons Lang >> >> 3.6 >> >> > based on RC3. >> >> > The following issues have been fixed since RC2: >> >> > >> >> > - Site build now works from source distribution >> >> > - IBM JDK test failures have been fixed >> >> > - Automatic-Module-Name MANIFEST entry has been added for Java 9 >> >> > compatibility >> >> > >> >> > Commons Lang 3.6 R3 is available for review here: >> >> > https://dist.apache.org/repos/dist/dev/commons/lang (svn revision >> >> 19928) >> >> > >> >> > The tag is here: >> >> > https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h= >> >> > e454e79463ffbbd9114db43019dd211debbcc105 >> >> > >> >> > Commit ID the tag points at: >> >> > 360198dfb6a2d68f1702f616dfacee34ae0541bb >> >> > >> >> > Maven Artifacts: >> >> > https://repository.apache.org/content/repositories/ >> >> orgapachecommons-1250 >> >> > >> >> > These are the Maven artifacts and their hashes: >> >> > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar >> >> > (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6- >> sources.jar.asc >> >> > (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc >> >> > (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom >> >> > (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc >> >> > (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6- >> javadoc.jar.asc >> >> > (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar >> >> > (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar >> >> > (SHA1: e58ba08b01d37a023746f0987dcd910036a63021) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc >> >> > (SHA1: af050e8c29a801a5d6783268c56230b814f56240) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6- >> >> > test-sources.jar.asc >> >> > (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6- >> test-sources.jar >> >> > (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea) >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar >> >> > (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f) >> >> > >> >> > I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven >> 3.5.0. >> >> > >> >> > Details of changes since 3.5 are in the release notes: >> >> > https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE- >> NOTES.txt >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_ >> >> > RC3/changes-report.html >> >> > >> >> > Site: >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3 >> >> > (note some *relative* links are broken and the 3.6 directories are >> >> > not yet created - these will be OK once the site is deployed) >> >> > >> >> > Clirr Report (compared to 3.5): >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_ >> >> > RC3/clirr-report.html >> >> > >> >> > RAT Report: >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_ >> >> > RC3/rat-report.html >> >> > >> >> > KEYS: >> >> > https://www.apache.org/dist/commons/KEYS >> >> > >> >> > Please review the release candidate and vote. >> >> > This vote will close no sooner that 72 hours from now, >> >> > i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017 >> >> > >> >> > [ ] +1 Release these artifacts >> >> > [ ] +0 OK, but... >> >> > [ ] -0 OK, but really should fix... >> >> > [ ] -1 I oppose this release because... >> >> > >> >> > Thanks! >> >> > Benedikt >> >> > --------------------------------------------------------------------- >> >> > 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
