Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Benedikt Ritter]

Hello, 
> Am 09.06.2017 um 11:25 schrieb sebb :
> 
> 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  wrote:
>> 
>>> Am 09.06.2017 um 08:44 schrieb Duncan Jones :
>>> 
>>> On Fri, 9 Jun 2017 at 02:35, Gary Gregory  wrote:
>>> 
 On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  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  wrote:
> 
>> On 8 June 2017 at 18:09, Gary Gregory  wrote:
>>> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
>>> 
 On 8 June 2017 at 17:19, Gary Gregory 
 wrote:
> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
>> 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.
 
>>> 
>>> 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[sebb]

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  wrote:
>
>> Am 09.06.2017 um 08:44 schrieb Duncan Jones :
>>
>> On Fri, 9 Jun 2017 at 02:35, Gary Gregory  wrote:
>>
>>> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  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  wrote:

> On 8 June 2017 at 18:09, Gary Gregory  wrote:
>> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
>>
>>> On 8 June 2017 at 17:19, Gary Gregory 
>>> wrote:
 On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> 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 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Benedikt Ritter]

> Am 09.06.2017 um 08:44 schrieb Duncan Jones :
> 
> On Fri, 9 Jun 2017 at 02:35, Gary Gregory  wrote:
> 
>> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  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  wrote:
>>> 
 On 8 June 2017 at 18:09, Gary Gregory  wrote:
> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> 
>> On 8 June 2017 at 17:19, Gary Gregory 
>> wrote:
>>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
 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 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Duncan Jones]

On Fri, 9 Jun 2017 at 02:35, Gary Gregory  wrote:

> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  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  wrote:
> >
> > > On 8 June 2017 at 18:09, Gary Gregory  wrote:
> > > > On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> > > >
> > > >> On 8 June 2017 at 17:19, Gary Gregory 
> wrote:
> > > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> > > 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
> > > >
> > > >
> > > >>
> > > >> >
> > 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Benedikt Ritter]

Hi,

> Am 09.06.2017 um 03:34 schrieb Gary Gregory :
> 
> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  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  wrote:
>> 
>>> On 8 June 2017 at 18:09, Gary Gregory  wrote:
 On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
 
> On 8 June 2017 at 17:19, Gary Gregory  wrote:
>> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
>>> 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

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero  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  wrote:
>
> > On 8 June 2017 at 18:09, Gary Gregory  wrote:
> > > On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> > >
> > >> On 8 June 2017 at 17:19, Gary Gregory  wrote:
> > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> > 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).
> > >> 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Simon Spero]

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

> On 8 June 2017 at 18:09, Gary Gregory  wrote:
> > On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
> >
> >> On 8 June 2017 at 17:19, Gary Gregory  wrote:
> >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero 
> 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" 
> 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[sebb]

On 8 June 2017 at 18:09, Gary Gregory  wrote:
> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
>
>> On 8 June 2017 at 17:19, Gary Gregory  wrote:
>> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  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"  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)
>> >> > 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Rob Tompkins]

+1 (non-binding)
Signatures ok
mvn clean site works in distro. 

> On Jun 8, 2017, at 1:09 PM, Gary Gregory  wrote:
> 
>> On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:
>> 
>>> On 8 June 2017 at 17:19, Gary Gregory  wrote:
 On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  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"  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: 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

On Thu, Jun 8, 2017 at 9:57 AM, sebb  wrote:

> On 8 June 2017 at 17:19, Gary Gregory  wrote:
> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  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"  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)
> >> > 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

+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  wrote:

> Hello,
>
> we have fixed quite a few bugs and added some nice new features since
> Commons Lang 3.5 was released, so I would like to release Commons Lang 3.6
> based on RC3.
> The following issues have been fixed since RC2:
>
> - Site build now works from source distribution
> - IBM JDK test failures have been fixed
> - Automatic-Module-Name MANIFEST entry has been added for Java 9
> compatibility
>
> Commons Lang 3.6 R3 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision 19928)
>
> The tag is here:
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> e454e79463ffbbd9114db43019dd211debbcc105
>
> Commit ID the tag points at:
>  360198dfb6a2d68f1702f616dfacee34ae0541bb
>
> Maven Artifacts:
>  https://repository.apache.org/content/repositories/orgapachecommons-1250
>
> These are the Maven artifacts and their hashes:
>
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
> (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
> (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
> (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
> (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> test-sources.jar.asc
> (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
> (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar
> (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)
>
> I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.
>
> Details of changes since 3.5 are in the release notes:
>https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/changes-report.html
>
> Site:
>  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3
>  (note some *relative* links are broken and the 3.6 directories are
>  not yet created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 3.5):
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/clirr-report.html
>
> RAT Report:
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/rat-report.html
>
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017
>
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[sebb]

On 8 June 2017 at 17:19, Gary Gregory  wrote:
> On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  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"  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

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Gary Gregory]

On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero  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"  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
> >
> > 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Simon Spero]

[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"  wrote:

> Hello,
>
> we have fixed quite a few bugs and added some nice new features since
> Commons Lang 3.5 was released, so I would like to release Commons Lang 3.6
> based on RC3.
> The following issues have been fixed since RC2:
>
> - Site build now works from source distribution
> - IBM JDK test failures have been fixed
> - Automatic-Module-Name MANIFEST entry has been added for Java 9
> compatibility
>
> Commons Lang 3.6 R3 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/lang (svn revision 19928)
>
> The tag is here:
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=
> e454e79463ffbbd9114db43019dd211debbcc105
>
> Commit ID the tag points at:
>  360198dfb6a2d68f1702f616dfacee34ae0541bb
>
> Maven Artifacts:
>  https://repository.apache.org/content/repositories/orgapachecommons-1250
>
> These are the Maven artifacts and their hashes:
>
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar
> (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar.asc
> (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-javadoc.jar.asc
> (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-sources.jar
> (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc
> (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> test-sources.jar.asc
> (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar
> (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar
> (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)
>
> I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using Maven 3.5.0.
>
> Details of changes since 3.5 are in the release notes:
>https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-NOTES.txt
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/changes-report.html
>
> Site:
>  http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3
>  (note some *relative* links are broken and the 3.6 directories are
>  not yet created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 3.5):
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/clirr-report.html
>
> RAT Report:
>http://home.apache.org/~britter/commons/lang/LANG_3_6_
> RC3/rat-report.html
>
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017
>
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: 

Re: [VOTE] Release Apache Commons Lang 3.6 based on RC3

[Bruno P. Kinoshita]

[ 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 
To: Commons Developers List  
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-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org