You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2017/06/08 08:48:09 UTC
[VOTE] Release Apache Commons Lang 3.6 based on RC3
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
+1.
From src zip: ASC, MD5, SHA1 OK. RAT and Clirr OK. Clirr does have the
warnings discussed on this thread.
Running 'mvn clean site' passes with:
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T12:39:06-07:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
and:
java version "1.8.0"
Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4 FP5))
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392 (JIT
enabled, AOT enabled)
J9VM - R28_20170419_1004_B344392
JIT - tr.r14.java_20170419_344392
GC - R28_20170419_1004_B344392
J9CL - 20170419_344392)
JCL - 20170420_01 based on Oracle jdk8u131-b11
But runs out of memory building the site with Oracle Java 7's default
settings.
Gary
On Thu, Jun 8, 2017 at 1:48 AM, Benedikt Ritter <br...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
[ X ] +1 Release these artifacts
Build passing for Oracle JDK 7, Oracle JDK 8, and IBM JDK 8.
Thanks a lot for preparing the release,
Bruno
________________________________
From: Benedikt Ritter <br...@apache.org>
To: Commons Developers List <de...@commons.apache.org>
Sent: Thursday, 8 June 2017 8:48 PM
Subject: [VOTE] Release Apache Commons Lang 3.6 based on RC3
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
Hi,
> Am 09.06.2017 um 03:34 schrieb Gary Gregory <ga...@gmail.com>:
>
> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <se...@gmail.com> wrote:
>
>> There is a one other compatibility issue, which can be seen in the attached
>> code:
>>
>> import java.nio.charset.StandardCharsets;
>>
>> public class Weasel {
>>
>> private static final String US_ASCII = "US-ASCII";
>> private static final String UTF_8 = "UTF-8";
>> private static final String STANDARD_US_ASCII =
>> StandardCharsets.US_ASCII.name();
>> private static final String STANDARD_UTF_8 =
>> StandardCharsets.UTF_8.name
>> ();
>>
>> public static void main(String[] args) {
>>
>> switch (args[0]) {
>> case US_ASCII:
>> System.out.println("USA! USA!");
>> break;
>> case UTF_8:
>> System.out.println("Emoji Lovin' Hippies!");
>> break;
>> default:
>> System.out.println("Weirdo.");
>> }
>> }
>> }
>>
>>
>> This code compiles.
>> However, if the case labels are changed to STANDARD_US_ASCII and
>> STANDARD_UTF_8, the compilation will fail, because the case labels are no
>> longer constant expressions.
>> In the actual code, this means that code compiled against an older version
>> of the library would work against the new code (because the old strings had
>> already been inlined), but could not be re-compiled.
>>
>
> Thank you for doing this research and POC :-)
>
> But Ugh! :-( We shot ourselves in the foot here.
>
> Benedikt, how do you feel about a fix and a new RC?
I can do it, no problem. Will start right away.
Cheers,
Benedikt
>
> Gary
>
>
>>
>> I don't know why anyone would be doing this...
>>
>> (CLIRR pre-dates string switches)
>>
>> Simon
>>
>> On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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-820a48456e11e85bf6cf5356c1aed4
>> baR48
>>>>>>>
>>>>>>> [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" <br...@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
Hello,
> Am 09.06.2017 um 11:25 schrieb sebb <se...@gmail.com>:
>
> If the intention of the change was to ensure that the values were
> correct, then there are two alternative option:
>
> 1) add a test to check the values
I’ve implemented this proposal in 5ffb6620
> 2) add assertions in the class to check the values
>
>
>
> On 9 June 2017 at 08:07, Benedikt Ritter <br...@apache.org> wrote:
>>
>>> Am 09.06.2017 um 08:44 schrieb Duncan Jones <du...@wortharead.com>:
>>>
>>> On Fri, 9 Jun 2017 at 02:35, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <se...@gmail.com> wrote:
>>>>
>>>>> There is a one other compatibility issue, which can be seen in the
>>>> attached
>>>>> code:
>>>>>
>>>>> import java.nio.charset.StandardCharsets;
>>>>>
>>>>> public class Weasel {
>>>>>
>>>>> private static final String US_ASCII = "US-ASCII";
>>>>> private static final String UTF_8 = "UTF-8";
>>>>> private static final String STANDARD_US_ASCII =
>>>>> StandardCharsets.US_ASCII.name();
>>>>> private static final String STANDARD_UTF_8 =
>>>>> StandardCharsets.UTF_8.name
>>>>> ();
>>>>>
>>>>> public static void main(String[] args) {
>>>>>
>>>>> switch (args[0]) {
>>>>> case US_ASCII:
>>>>> System.out.println("USA! USA!");
>>>>> break;
>>>>> case UTF_8:
>>>>> System.out.println("Emoji Lovin' Hippies!");
>>>>> break;
>>>>> default:
>>>>> System.out.println("Weirdo.");
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> This code compiles.
>>>>> However, if the case labels are changed to STANDARD_US_ASCII and
>>>>> STANDARD_UTF_8, the compilation will fail, because the case labels are
>>>> no
>>>>> longer constant expressions.
>>>>> In the actual code, this means that code compiled against an older
>>>> version
>>>>> of the library would work against the new code (because the old strings
>>>> had
>>>>> already been inlined), but could not be re-compiled.
>>>>>
>>>>
>>>> Thank you for doing this research and POC :-)
>>>>
>>>> But Ugh! :-( We shot ourselves in the foot here.
>>>
>>>
>>> D'oh. Sorry about that guys :-(
>>
>> No problem!
>>
>>>
>>>
>>>>
>>>> Benedikt, how do you feel about a fix and a new RC?
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> I don't know why anyone would be doing this...
>>>>>
>>>>> (CLIRR pre-dates string switches)
>>>>>
>>>>> Simon
>>>>>
>>>>> On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>>>>>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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-820a48456e11e85bf6cf5356c1aed4
>>>>> baR48
>>>>>>>>>>
>>>>>>>>>> [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" <br...@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-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by sebb <se...@gmail.com>.
If the intention of the change was to ensure that the values were
correct, then there are two alternative option:
1) add a test to check the values
2) add assertions in the class to check the values
On 9 June 2017 at 08:07, Benedikt Ritter <br...@apache.org> wrote:
>
>> Am 09.06.2017 um 08:44 schrieb Duncan Jones <du...@wortharead.com>:
>>
>> On Fri, 9 Jun 2017 at 02:35, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <se...@gmail.com> wrote:
>>>
>>>> There is a one other compatibility issue, which can be seen in the
>>> attached
>>>> code:
>>>>
>>>> import java.nio.charset.StandardCharsets;
>>>>
>>>> public class Weasel {
>>>>
>>>> private static final String US_ASCII = "US-ASCII";
>>>> private static final String UTF_8 = "UTF-8";
>>>> private static final String STANDARD_US_ASCII =
>>>> StandardCharsets.US_ASCII.name();
>>>> private static final String STANDARD_UTF_8 =
>>>> StandardCharsets.UTF_8.name
>>>> ();
>>>>
>>>> public static void main(String[] args) {
>>>>
>>>> switch (args[0]) {
>>>> case US_ASCII:
>>>> System.out.println("USA! USA!");
>>>> break;
>>>> case UTF_8:
>>>> System.out.println("Emoji Lovin' Hippies!");
>>>> break;
>>>> default:
>>>> System.out.println("Weirdo.");
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>> This code compiles.
>>>> However, if the case labels are changed to STANDARD_US_ASCII and
>>>> STANDARD_UTF_8, the compilation will fail, because the case labels are
>>> no
>>>> longer constant expressions.
>>>> In the actual code, this means that code compiled against an older
>>> version
>>>> of the library would work against the new code (because the old strings
>>> had
>>>> already been inlined), but could not be re-compiled.
>>>>
>>>
>>> Thank you for doing this research and POC :-)
>>>
>>> But Ugh! :-( We shot ourselves in the foot here.
>>
>>
>> D'oh. Sorry about that guys :-(
>
> No problem!
>
>>
>>
>>>
>>> Benedikt, how do you feel about a fix and a new RC?
>>>
>>> Gary
>>>
>>>
>>>>
>>>> I don't know why anyone would be doing this...
>>>>
>>>> (CLIRR pre-dates string switches)
>>>>
>>>> Simon
>>>>
>>>> On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>>>>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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-820a48456e11e85bf6cf5356c1aed4
>>>> baR48
>>>>>>>>>
>>>>>>>>> [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" <br...@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-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
> Am 09.06.2017 um 08:44 schrieb Duncan Jones <du...@wortharead.com>:
>
> On Fri, 9 Jun 2017 at 02:35, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <se...@gmail.com> wrote:
>>
>>> There is a one other compatibility issue, which can be seen in the
>> attached
>>> code:
>>>
>>> import java.nio.charset.StandardCharsets;
>>>
>>> public class Weasel {
>>>
>>> private static final String US_ASCII = "US-ASCII";
>>> private static final String UTF_8 = "UTF-8";
>>> private static final String STANDARD_US_ASCII =
>>> StandardCharsets.US_ASCII.name();
>>> private static final String STANDARD_UTF_8 =
>>> StandardCharsets.UTF_8.name
>>> ();
>>>
>>> public static void main(String[] args) {
>>>
>>> switch (args[0]) {
>>> case US_ASCII:
>>> System.out.println("USA! USA!");
>>> break;
>>> case UTF_8:
>>> System.out.println("Emoji Lovin' Hippies!");
>>> break;
>>> default:
>>> System.out.println("Weirdo.");
>>> }
>>> }
>>> }
>>>
>>>
>>> This code compiles.
>>> However, if the case labels are changed to STANDARD_US_ASCII and
>>> STANDARD_UTF_8, the compilation will fail, because the case labels are
>> no
>>> longer constant expressions.
>>> In the actual code, this means that code compiled against an older
>> version
>>> of the library would work against the new code (because the old strings
>> had
>>> already been inlined), but could not be re-compiled.
>>>
>>
>> Thank you for doing this research and POC :-)
>>
>> But Ugh! :-( We shot ourselves in the foot here.
>
>
> D'oh. Sorry about that guys :-(
No problem!
>
>
>>
>> Benedikt, how do you feel about a fix and a new RC?
>>
>> Gary
>>
>>
>>>
>>> I don't know why anyone would be doing this...
>>>
>>> (CLIRR pre-dates string switches)
>>>
>>> Simon
>>>
>>> On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>>>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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-820a48456e11e85bf6cf5356c1aed4
>>> baR48
>>>>>>>>
>>>>>>>> [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" <br...@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-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Duncan Jones <du...@wortharead.com>.
On Fri, 9 Jun 2017 at 02:35, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <se...@gmail.com> wrote:
>
> > There is a one other compatibility issue, which can be seen in the
> attached
> > code:
> >
> > import java.nio.charset.StandardCharsets;
> >
> > public class Weasel {
> >
> > private static final String US_ASCII = "US-ASCII";
> > private static final String UTF_8 = "UTF-8";
> > private static final String STANDARD_US_ASCII =
> > StandardCharsets.US_ASCII.name();
> > private static final String STANDARD_UTF_8 =
> > StandardCharsets.UTF_8.name
> > ();
> >
> > public static void main(String[] args) {
> >
> > switch (args[0]) {
> > case US_ASCII:
> > System.out.println("USA! USA!");
> > break;
> > case UTF_8:
> > System.out.println("Emoji Lovin' Hippies!");
> > break;
> > default:
> > System.out.println("Weirdo.");
> > }
> > }
> > }
> >
> >
> > This code compiles.
> > However, if the case labels are changed to STANDARD_US_ASCII and
> > STANDARD_UTF_8, the compilation will fail, because the case labels are
> no
> > longer constant expressions.
> > In the actual code, this means that code compiled against an older
> version
> > of the library would work against the new code (because the old strings
> had
> > already been inlined), but could not be re-compiled.
> >
>
> Thank you for doing this research and POC :-)
>
> But Ugh! :-( We shot ourselves in the foot here.
D'oh. Sorry about that guys :-(
>
> Benedikt, how do you feel about a fix and a new RC?
>
> Gary
>
>
> >
> > I don't know why anyone would be doing this...
> >
> > (CLIRR pre-dates string switches)
> >
> > Simon
> >
> > On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
> >
> > > On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
> > > > On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
> > > >
> > > >> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com>
> wrote:
> > > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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-820a48456e11e85bf6cf5356c1aed4
> > baR48
> > > >> >>
> > > >> >> [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" <br...@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-unsubscribe@commons.apache.org
> > > >> >> > For additional commands, e-mail: dev-help@commons.apache.org
> > > >> >> >
> > > >> >> >
> > > >> >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <se...@gmail.com> wrote:
> There is a one other compatibility issue, which can be seen in the attached
> code:
>
> import java.nio.charset.StandardCharsets;
>
> public class Weasel {
>
> private static final String US_ASCII = "US-ASCII";
> private static final String UTF_8 = "UTF-8";
> private static final String STANDARD_US_ASCII =
> StandardCharsets.US_ASCII.name();
> private static final String STANDARD_UTF_8 =
> StandardCharsets.UTF_8.name
> ();
>
> public static void main(String[] args) {
>
> switch (args[0]) {
> case US_ASCII:
> System.out.println("USA! USA!");
> break;
> case UTF_8:
> System.out.println("Emoji Lovin' Hippies!");
> break;
> default:
> System.out.println("Weirdo.");
> }
> }
> }
>
>
> This code compiles.
> However, if the case labels are changed to STANDARD_US_ASCII and
> STANDARD_UTF_8, the compilation will fail, because the case labels are no
> longer constant expressions.
> In the actual code, this means that code compiled against an older version
> of the library would work against the new code (because the old strings had
> already been inlined), but could not be re-compiled.
>
Thank you for doing this research and POC :-)
But Ugh! :-( We shot ourselves in the foot here.
Benedikt, how do you feel about a fix and a new RC?
Gary
>
> I don't know why anyone would be doing this...
>
> (CLIRR pre-dates string switches)
>
> Simon
>
> On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
>
> > On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
> > > On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
> > >
> > >> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
> > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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-820a48456e11e85bf6cf5356c1aed4
> baR48
> > >> >>
> > >> >> [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" <br...@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-unsubscribe@commons.apache.org
> > >> >> > For additional commands, e-mail: dev-help@commons.apache.org
> > >> >> >
> > >> >> >
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Simon Spero <se...@gmail.com>.
There is a one other compatibility issue, which can be seen in the attached
code:
import java.nio.charset.StandardCharsets;
public class Weasel {
private static final String US_ASCII = "US-ASCII";
private static final String UTF_8 = "UTF-8";
private static final String STANDARD_US_ASCII =
StandardCharsets.US_ASCII.name();
private static final String STANDARD_UTF_8 = StandardCharsets.UTF_8.name
();
public static void main(String[] args) {
switch (args[0]) {
case US_ASCII:
System.out.println("USA! USA!");
break;
case UTF_8:
System.out.println("Emoji Lovin' Hippies!");
break;
default:
System.out.println("Weirdo.");
}
}
}
This code compiles.
However, if the case labels are changed to STANDARD_US_ASCII and
STANDARD_UTF_8, the compilation will fail, because the case labels are no
longer constant expressions.
In the actual code, this means that code compiled against an older version
of the library would work against the new code (because the old strings had
already been inlined), but could not be re-compiled.
I don't know why anyone would be doing this...
(CLIRR pre-dates string switches)
Simon
On Thu, Jun 8, 2017 at 5:10 PM, sebb <se...@gmail.com> wrote:
> On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
> > On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
> >
> >> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
> >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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" <br...@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-unsubscribe@commons.apache.org
> >> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >
> >> >> >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by sebb <se...@gmail.com>.
On 8 June 2017 at 18:09, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
>
>> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
>> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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" <br...@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-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Rob Tompkins <ch...@gmail.com>.
+1 (non-binding)
Signatures ok
mvn clean site works in distro.
> On Jun 8, 2017, at 1:09 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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? 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" <br...@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jun 8, 2017 at 9:57 AM, sebb <se...@gmail.com> wrote:
> On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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? 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" <br...@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-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by sebb <se...@gmail.com>.
On 8 June 2017 at 17:19, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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.
>
>> 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" <br...@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-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <se...@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?
> 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" <br...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Simon Spero <se...@gmail.com>.
[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.
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?
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).
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" <br...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
[CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC3
Posted by Benedikt Ritter <br...@apache.org>.
> Am 08.06.2017 um 10:48 schrieb Benedikt Ritter <br...@apache.org>:
>
> 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…
This vote is canceled because of the compatibility issues detected in the CharEncoding class. Thanks to Simon Sperr for spotting this issue.
Regards,
Benedikt
>
> Thanks!
> Benedikt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org