date:20180329

Re: [collections] breaking changes

2018-03-29 Thread Paul King

Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Bridger itself is built with Maven.

On Fri, Mar 30, 2018 at 12:20 PM, Paul King  wrote:
> In the Groovy build we do this using Bridger
> (https://github.com/dmlloyd/bridger). It's built with gradle (and uses
> Ant). They have a Maven plugin but I haven't used it.
>
> In our build we have this:
>
> compileJava {
> doLast {
> ant.java(classname:'org.jboss.bridger.Bridger', classpath:
> rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
> arg(value:
> "${sourceSets.main.java.outputDir.canonicalPath}/org/codehaus/groovy/runtime/DefaultGroovyMethods.class")
> }
> ant.echo('Bridger: ' + ant.properties.stdout)
> }
> }
>
> And in the relevant source file we have a small number of $$bridge
> methods like this one:
>
> public static  List withDefault$$bridge(List self, Closure init) {
> return withDefault(self, init);
> }
>
> to match the original methods we are duplicating, e.g.:
>
> public static  ListWithDefault withDefault(List self,
> Closure init) {
> // ... code here ...
> }
>
> Cheers, Paul.
>
> On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka  wrote:
>> This could be solved if it were possible to force javac to generate bridge
>> methods. There's an extension which would allow that here:
>> https://github.com/infradna/bridge-method-injector, but I suspect it would
>> complicate the build process quite a bit.
>>
>> On Thu, Mar 29, 2018 at 4:48 PM sebb  wrote:
>>
>>> The return type is part of the method signature that Java uses to find
>>> resolve references.
>>>
>>> Even changing from void to non-void will cause binary incompatibility.
>>> (Source-wise, that's fine)
>>>
>>> On 29 March 2018 at 18:20, Gary Gregory  wrote:
>>> > Yep, that's no good. I'll revert.
>>> >
>>> > Gary
>>> >
>>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
>>> > wrote:
>>> >
>>> >> I haven't looked into the IteratorUtils class at all but it's easy to
>>> >> show binary incompatibility when changing the return type.
>>> >> Compile this "library" class:
>>> >>
>>> >> import java.util.ArrayList;
>>> >> import java.util.List;
>>> >>
>>> >> public class Lib {
>>> >> List getMyList() {
>>> >> return new ArrayList();
>>> >> }
>>> >> }
>>> >>
>>> >> Now compile this user of the library:
>>> >>
>>> >> import java.util.List;
>>> >>
>>> >> public class Main {
>>> >> public static void main(String[] args) {
>>> >> doit(new Lib().getMyList());
>>> >> }
>>> >>
>>> >> private static void doit(List list) {
>>> >> System.out.println("list is: " + list);
>>> >> }
>>> >> }
>>> >>
>>> >>
>>> >> Ensure it all works:
>>> >>
>>> >> > java -cp path_to_lib Main
>>> >>
>>> >> Should output:
>>> >>
>>> >> List is: []
>>> >>
>>> >> Now change the Lib class to return ArrayList instead of List and
>>> >> recompile just the Lib class (i.e. importantly don't recompile Main).
>>> >>
>>> >> Now if you try:
>>> >>
>>> >> > java -cp path_to_lib Main
>>> >>
>>> >> you should see:
>>> >>
>>> >> Exception in thread "main" java.lang.NoSuchMethodError:
>>> >> Lib.getMyList()Ljava/util/List;
>>> >> at Main.main(Main.java:5)
>>> >>
>>> >> Cheers, Paul.
>>> >>
>>> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
>>> >> wrote:
>>> >> > Can you show how older code would not function. Aside from using
>>> >> reflection.
>>> >> >
>>> >> > Gary
>>> >> >
>>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
>>> >> >
>>> >> >> if we are using semantic numbering would this not cause a major
>>> revision
>>> >> >> change as older code will no longer function?
>>> >> >>
>>> >> >> Claude
>>> >> >>
>>> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <
>>> garydgreg...@gmail.com>
>>> >> >> wrote:
>>> >> >>
>>> >> >> > Hi All:
>>> >> >> >
>>> >> >> > Updating Commons Collections' commons-parent from version 43 to 45
>>> >> causes
>>> >> >> > the build to fail due to the use of japicmp which reports:
>>> >> >> >
>>> >> >> > [ERROR] Failed to execute goal
>>> >> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)
>>> on
>>> >> >> > project commons-collections4: Error generating
>>> >> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
>>> >> report:
>>> >> >> > Breaking the build because there is at least one incompatibility:
>>> >> >> > org.apache.commons.collections4.IteratorUtils.
>>> >> peekingIterator(java.util.
>>> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
>>> >> >> > collections4.IteratorUtils.pushbackIterator(java.util.
>>> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
>>> >> >> > -> [Help 1]
>>> >> >> >
>>> >> >> > This is caused by:
>>> >> >> >
>>> >> >> > - [COLLECTIONS-676] Modify

Re: [collections] breaking changes

2018-03-29 Thread Paul King

In the Groovy build we do this using Bridger
(https://github.com/dmlloyd/bridger). It's built with gradle (and uses
Ant). They have a Maven plugin but I haven't used it.

In our build we have this:

compileJava {
doLast {
ant.java(classname:'org.jboss.bridger.Bridger', classpath:
rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
arg(value:
"${sourceSets.main.java.outputDir.canonicalPath}/org/codehaus/groovy/runtime/DefaultGroovyMethods.class")
}
ant.echo('Bridger: ' + ant.properties.stdout)
}
}

And in the relevant source file we have a small number of $$bridge
methods like this one:

public static  List withDefault$$bridge(List self, Closure init) {
return withDefault(self, init);
}

to match the original methods we are duplicating, e.g.:

public static  ListWithDefault withDefault(List self,
Closure init) {
// ... code here ...
}

Cheers, Paul.

On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka  wrote:
> This could be solved if it were possible to force javac to generate bridge
> methods. There's an extension which would allow that here:
> https://github.com/infradna/bridge-method-injector, but I suspect it would
> complicate the build process quite a bit.
>
> On Thu, Mar 29, 2018 at 4:48 PM sebb  wrote:
>
>> The return type is part of the method signature that Java uses to find
>> resolve references.
>>
>> Even changing from void to non-void will cause binary incompatibility.
>> (Source-wise, that's fine)
>>
>> On 29 March 2018 at 18:20, Gary Gregory  wrote:
>> > Yep, that's no good. I'll revert.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
>> > wrote:
>> >
>> >> I haven't looked into the IteratorUtils class at all but it's easy to
>> >> show binary incompatibility when changing the return type.
>> >> Compile this "library" class:
>> >>
>> >> import java.util.ArrayList;
>> >> import java.util.List;
>> >>
>> >> public class Lib {
>> >> List getMyList() {
>> >> return new ArrayList();
>> >> }
>> >> }
>> >>
>> >> Now compile this user of the library:
>> >>
>> >> import java.util.List;
>> >>
>> >> public class Main {
>> >> public static void main(String[] args) {
>> >> doit(new Lib().getMyList());
>> >> }
>> >>
>> >> private static void doit(List list) {
>> >> System.out.println("list is: " + list);
>> >> }
>> >> }
>> >>
>> >>
>> >> Ensure it all works:
>> >>
>> >> > java -cp path_to_lib Main
>> >>
>> >> Should output:
>> >>
>> >> List is: []
>> >>
>> >> Now change the Lib class to return ArrayList instead of List and
>> >> recompile just the Lib class (i.e. importantly don't recompile Main).
>> >>
>> >> Now if you try:
>> >>
>> >> > java -cp path_to_lib Main
>> >>
>> >> you should see:
>> >>
>> >> Exception in thread "main" java.lang.NoSuchMethodError:
>> >> Lib.getMyList()Ljava/util/List;
>> >> at Main.main(Main.java:5)
>> >>
>> >> Cheers, Paul.
>> >>
>> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
>> >> wrote:
>> >> > Can you show how older code would not function. Aside from using
>> >> reflection.
>> >> >
>> >> > Gary
>> >> >
>> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
>> >> >
>> >> >> if we are using semantic numbering would this not cause a major
>> revision
>> >> >> change as older code will no longer function?
>> >> >>
>> >> >> Claude
>> >> >>
>> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >> > Hi All:
>> >> >> >
>> >> >> > Updating Commons Collections' commons-parent from version 43 to 45
>> >> causes
>> >> >> > the build to fail due to the use of japicmp which reports:
>> >> >> >
>> >> >> > [ERROR] Failed to execute goal
>> >> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)
>> on
>> >> >> > project commons-collections4: Error generating
>> >> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
>> >> report:
>> >> >> > Breaking the build because there is at least one incompatibility:
>> >> >> > org.apache.commons.collections4.IteratorUtils.
>> >> peekingIterator(java.util.
>> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
>> >> >> > collections4.IteratorUtils.pushbackIterator(java.util.
>> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
>> >> >> > -> [Help 1]
>> >> >> >
>> >> >> > This is caused by:
>> >> >> >
>> >> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator
>> signature to
>> >> >> > return PushbackIterator.
>> >> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature
>> to
>> >> >> > return PeekingIterator.
>> >> >> >
>> >> >> > Which are reasonable changes IMO.
>> >> >> >
>> >> >> > Does anyone object to these changes and adding exceptions to allow
>> >> >> japicmp
>> >> >> > to
>> >> >> > not fail the build?
>> >> >> >
>> >> >> > Thank you,
>>

Re: [collections] breaking changes

2018-03-29 Thread Peter Burka

This could be solved if it were possible to force javac to generate bridge
methods. There's an extension which would allow that here:
https://github.com/infradna/bridge-method-injector, but I suspect it would
complicate the build process quite a bit.

On Thu, Mar 29, 2018 at 4:48 PM sebb  wrote:

> The return type is part of the method signature that Java uses to find
> resolve references.
>
> Even changing from void to non-void will cause binary incompatibility.
> (Source-wise, that's fine)
>
> On 29 March 2018 at 18:20, Gary Gregory  wrote:
> > Yep, that's no good. I'll revert.
> >
> > Gary
> >
> > On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
> > wrote:
> >
> >> I haven't looked into the IteratorUtils class at all but it's easy to
> >> show binary incompatibility when changing the return type.
> >> Compile this "library" class:
> >>
> >> import java.util.ArrayList;
> >> import java.util.List;
> >>
> >> public class Lib {
> >> List getMyList() {
> >> return new ArrayList();
> >> }
> >> }
> >>
> >> Now compile this user of the library:
> >>
> >> import java.util.List;
> >>
> >> public class Main {
> >> public static void main(String[] args) {
> >> doit(new Lib().getMyList());
> >> }
> >>
> >> private static void doit(List list) {
> >> System.out.println("list is: " + list);
> >> }
> >> }
> >>
> >>
> >> Ensure it all works:
> >>
> >> > java -cp path_to_lib Main
> >>
> >> Should output:
> >>
> >> List is: []
> >>
> >> Now change the Lib class to return ArrayList instead of List and
> >> recompile just the Lib class (i.e. importantly don't recompile Main).
> >>
> >> Now if you try:
> >>
> >> > java -cp path_to_lib Main
> >>
> >> you should see:
> >>
> >> Exception in thread "main" java.lang.NoSuchMethodError:
> >> Lib.getMyList()Ljava/util/List;
> >> at Main.main(Main.java:5)
> >>
> >> Cheers, Paul.
> >>
> >> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
> >> wrote:
> >> > Can you show how older code would not function. Aside from using
> >> reflection.
> >> >
> >> > Gary
> >> >
> >> > On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
> >> >
> >> >> if we are using semantic numbering would this not cause a major
> revision
> >> >> change as older code will no longer function?
> >> >>
> >> >> Claude
> >> >>
> >> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <
> garydgreg...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Hi All:
> >> >> >
> >> >> > Updating Commons Collections' commons-parent from version 43 to 45
> >> causes
> >> >> > the build to fail due to the use of japicmp which reports:
> >> >> >
> >> >> > [ERROR] Failed to execute goal
> >> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)
> on
> >> >> > project commons-collections4: Error generating
> >> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
> >> report:
> >> >> > Breaking the build because there is at least one incompatibility:
> >> >> > org.apache.commons.collections4.IteratorUtils.
> >> peekingIterator(java.util.
> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
> >> >> > collections4.IteratorUtils.pushbackIterator(java.util.
> >> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
> >> >> > -> [Help 1]
> >> >> >
> >> >> > This is caused by:
> >> >> >
> >> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator
> signature to
> >> >> > return PushbackIterator.
> >> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature
> to
> >> >> > return PeekingIterator.
> >> >> >
> >> >> > Which are reasonable changes IMO.
> >> >> >
> >> >> > Does anyone object to these changes and adding exceptions to allow
> >> >> japicmp
> >> >> > to
> >> >> > not fail the build?
> >> >> >
> >> >> > Thank you,
> >> >> > Gary
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> I like: Like Like - The likeliest place on the web
> >> >> 
> >> >> LinkedIn: http://www.linkedin.com/in/claudewarren
> >> >>
> >>
> >> -
> >> 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
>
>

[httpclient] Better user agent header?

2018-03-29 Thread Gary Gregory

Hi All:

Right now, the HttpClient is of the form:

User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)

With the stack I am working with, it would be handy if the header reflected:

- The Java vendor
- Operating system name and version.

For example:

User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
Windows/10.0 (amd64)

Any thoughts for or against adding this to the user agent string?

Gary

Re: [collections] breaking changes

2018-03-29 Thread sebb

The return type is part of the method signature that Java uses to find
resolve references.

Even changing from void to non-void will cause binary incompatibility.
(Source-wise, that's fine)

On 29 March 2018 at 18:20, Gary Gregory  wrote:
> Yep, that's no good. I'll revert.
>
> Gary
>
> On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
> wrote:
>
>> I haven't looked into the IteratorUtils class at all but it's easy to
>> show binary incompatibility when changing the return type.
>> Compile this "library" class:
>>
>> import java.util.ArrayList;
>> import java.util.List;
>>
>> public class Lib {
>> List getMyList() {
>> return new ArrayList();
>> }
>> }
>>
>> Now compile this user of the library:
>>
>> import java.util.List;
>>
>> public class Main {
>> public static void main(String[] args) {
>> doit(new Lib().getMyList());
>> }
>>
>> private static void doit(List list) {
>> System.out.println("list is: " + list);
>> }
>> }
>>
>>
>> Ensure it all works:
>>
>> > java -cp path_to_lib Main
>>
>> Should output:
>>
>> List is: []
>>
>> Now change the Lib class to return ArrayList instead of List and
>> recompile just the Lib class (i.e. importantly don't recompile Main).
>>
>> Now if you try:
>>
>> > java -cp path_to_lib Main
>>
>> you should see:
>>
>> Exception in thread "main" java.lang.NoSuchMethodError:
>> Lib.getMyList()Ljava/util/List;
>> at Main.main(Main.java:5)
>>
>> Cheers, Paul.
>>
>> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
>> wrote:
>> > Can you show how older code would not function. Aside from using
>> reflection.
>> >
>> > Gary
>> >
>> > On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
>> >
>> >> if we are using semantic numbering would this not cause a major revision
>> >> change as older code will no longer function?
>> >>
>> >> Claude
>> >>
>> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory 
>> >> wrote:
>> >>
>> >> > Hi All:
>> >> >
>> >> > Updating Commons Collections' commons-parent from version 43 to 45
>> causes
>> >> > the build to fail due to the use of japicmp which reports:
>> >> >
>> >> > [ERROR] Failed to execute goal
>> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
>> >> > project commons-collections4: Error generating
>> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
>> report:
>> >> > Breaking the build because there is at least one incompatibility:
>> >> > org.apache.commons.collections4.IteratorUtils.
>> peekingIterator(java.util.
>> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
>> >> > collections4.IteratorUtils.pushbackIterator(java.util.
>> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
>> >> > -> [Help 1]
>> >> >
>> >> > This is caused by:
>> >> >
>> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
>> >> > return PushbackIterator.
>> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
>> >> > return PeekingIterator.
>> >> >
>> >> > Which are reasonable changes IMO.
>> >> >
>> >> > Does anyone object to these changes and adding exceptions to allow
>> >> japicmp
>> >> > to
>> >> > not fail the build?
>> >> >
>> >> > Thank you,
>> >> > Gary
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> I like: Like Like - The likeliest place on the web
>> >> 
>> >> LinkedIn: http://www.linkedin.com/in/claudewarren
>> >>
>>
>> -
>> 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

Re: [parent] release 46

2018-03-29 Thread Rob Tompkins



> On Mar 29, 2018, at 2:27 PM, Gary Gregory  wrote:
> 
>> On Thu, Mar 29, 2018 at 11:59 AM, Rob Tompkins  wrote:
>> 
>> I’ll do it. I want to do another release of the release-plugin. Will try
>> to get an RC out before Saturday.
>> 
> 
> Awesome :-)
> 
> Also note that Sebb updated commons-build-plugin and that might need a
> release first.

Gotcha. 

> 
> Gary
> 
> 
>>> On Mar 29, 2018, at 1:57 PM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> It would be nice to release commons-parent 46 in order to pick up the new
>>> version of Surefire which let's us test on Java 10.
>>> 
>>> Any volunteers?
>>> 
>>> Gary
>> 
>> -
>> 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

Re: [configuration] Java 8 types

2018-03-29 Thread Gary Gregory

Hi,

We are talking dead Java 7 here, Android or not, Java 10 just came out. It
looks like Android supports some Java 8 at least:
https://developer.android.com/studio/write/java8-support.html

If someone has a burning desire to maintain a Java 7 branch, go for it. I
do think that in 2018, we need to move off Java 7 for main Java
development...

Gary

On Thu, Mar 29, 2018 at 12:05 PM, Oliver Heger  wrote:

>
>
> Am 29.03.2018 um 15:54 schrieb Gary Gregory:
> > Done.
> >
> > Gary
> >
> > On Wed, Mar 28, 2018 at 2:21 PM, Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> >> +1
> >>
> >>
> >> On Wed, Mar 28, 2018 at 9:06 PM, Gary Gregory 
> >> wrote:
> >>> Hi All:
> >>>
> >>> I say it is time to update Commons Configuration to Java 8 and support
> >> the
> >>> types in java.time.
> >>>
> >>> Thoughts?
>
> Supporting these new types is certainly desirable.
>
> As the conversion mechanism is designed to be extensible, maybe this can
> be achieved without increasing the minimum Java requirement for the core
> library: We could add a module (making [configuration] to a multi-module
> project) that just contains a converter for new Java 8 types. This
> module would then obviously require Java 8.
>
> The API for installing this converter probably would need some tweaking
> to make the extension of the conversion mechanism more convenient. But
> this should be doable. The user guide [1] describes this mechanism and
> how to add custom converters.
>
> While I am not strictly against switching to Java 8, I fear that there
> are still users who have to stick to version 1.7, for instance on Android.
>
> Oliver
>
> [1]
> http://commons.apache.org/proper/commons-configuration/
> userguide/howto_basicfeatures.html#Data_type_conversions
>
> >>>
> >>> Gary
> >>
> >> -
> >> 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
>
>

Re: [parent] release 46

2018-03-29 Thread Gary Gregory

On Thu, Mar 29, 2018 at 11:59 AM, Rob Tompkins  wrote:

> I’ll do it. I want to do another release of the release-plugin. Will try
> to get an RC out before Saturday.
>

Awesome :-)

Also note that Sebb updated commons-build-plugin and that might need a
release first.

Gary


> > On Mar 29, 2018, at 1:57 PM, Gary Gregory 
> wrote:
> >
> > Hi All,
> >
> > It would be nice to release commons-parent 46 in order to pick up the new
> > version of Surefire which let's us test on Java 10.
> >
> > Any volunteers?
> >
> > Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [configuration] Java 8 types

2018-03-29 Thread Oliver Heger

Am 29.03.2018 um 15:54 schrieb Gary Gregory:
> Done.
> 
> Gary
> 
> On Wed, Mar 28, 2018 at 2:21 PM, Jochen Wiedmann 
> wrote:
> 
>> +1
>>
>>
>> On Wed, Mar 28, 2018 at 9:06 PM, Gary Gregory 
>> wrote:
>>> Hi All:
>>>
>>> I say it is time to update Commons Configuration to Java 8 and support
>> the
>>> types in java.time.
>>>
>>> Thoughts?

Supporting these new types is certainly desirable.

As the conversion mechanism is designed to be extensible, maybe this can
be achieved without increasing the minimum Java requirement for the core
library: We could add a module (making [configuration] to a multi-module
project) that just contains a converter for new Java 8 types. This
module would then obviously require Java 8.

The API for installing this converter probably would need some tweaking
to make the extension of the conversion mechanism more convenient. But
this should be doable. The user guide [1] describes this mechanism and
how to add custom converters.

While I am not strictly against switching to Java 8, I fear that there
are still users who have to stick to version 1.7, for instance on Android.

Oliver

[1]
http://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Data_type_conversions

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

Re: [parent] release 46

2018-03-29 Thread Rob Tompkins

I’ll do it. I want to do another release of the release-plugin. Will try to get 
an RC out before Saturday. 

> On Mar 29, 2018, at 1:57 PM, Gary Gregory  wrote:
> 
> Hi All,
> 
> It would be nice to release commons-parent 46 in order to pick up the new
> version of Surefire which let's us test on Java 10.
> 
> Any volunteers?
> 
> Gary

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

[parent] release 46

2018-03-29 Thread Gary Gregory

Hi All,

It would be nice to release commons-parent 46 in order to pick up the new
version of Surefire which let's us test on Java 10.

Any volunteers?

Gary

Re: [collections] breaking changes

2018-03-29 Thread Gary Gregory

Yep, that's no good. I'll revert.

Gary

On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
wrote:

> I haven't looked into the IteratorUtils class at all but it's easy to
> show binary incompatibility when changing the return type.
> Compile this "library" class:
>
> import java.util.ArrayList;
> import java.util.List;
>
> public class Lib {
> List getMyList() {
> return new ArrayList();
> }
> }
>
> Now compile this user of the library:
>
> import java.util.List;
>
> public class Main {
> public static void main(String[] args) {
> doit(new Lib().getMyList());
> }
>
> private static void doit(List list) {
> System.out.println("list is: " + list);
> }
> }
>
>
> Ensure it all works:
>
> > java -cp path_to_lib Main
>
> Should output:
>
> List is: []
>
> Now change the Lib class to return ArrayList instead of List and
> recompile just the Lib class (i.e. importantly don't recompile Main).
>
> Now if you try:
>
> > java -cp path_to_lib Main
>
> you should see:
>
> Exception in thread "main" java.lang.NoSuchMethodError:
> Lib.getMyList()Ljava/util/List;
> at Main.main(Main.java:5)
>
> Cheers, Paul.
>
> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
> wrote:
> > Can you show how older code would not function. Aside from using
> reflection.
> >
> > Gary
> >
> > On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
> >
> >> if we are using semantic numbering would this not cause a major revision
> >> change as older code will no longer function?
> >>
> >> Claude
> >>
> >> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory 
> >> wrote:
> >>
> >> > Hi All:
> >> >
> >> > Updating Commons Collections' commons-parent from version 43 to 45
> causes
> >> > the build to fail due to the use of japicmp which reports:
> >> >
> >> > [ERROR] Failed to execute goal
> >> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> >> > project commons-collections4: Error generating
> >> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate
> report:
> >> > Breaking the build because there is at least one incompatibility:
> >> > org.apache.commons.collections4.IteratorUtils.
> peekingIterator(java.util.
> >> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
> >> > collections4.IteratorUtils.pushbackIterator(java.util.
> >> > Iterator):METHOD_RETURN_TYPE_CHANGED
> >> > -> [Help 1]
> >> >
> >> > This is caused by:
> >> >
> >> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
> >> > return PushbackIterator.
> >> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
> >> > return PeekingIterator.
> >> >
> >> > Which are reasonable changes IMO.
> >> >
> >> > Does anyone object to these changes and adding exceptions to allow
> >> japicmp
> >> > to
> >> > not fail the build?
> >> >
> >> > Thank you,
> >> > Gary
> >> >
> >>
> >>
> >>
> >> --
> >> I like: Like Like - The likeliest place on the web
> >> 
> >> LinkedIn: http://www.linkedin.com/in/claudewarren
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [collections] breaking changes

2018-03-29 Thread Paul King

I haven't looked into the IteratorUtils class at all but it's easy to
show binary incompatibility when changing the return type.
Compile this "library" class:

import java.util.ArrayList;
import java.util.List;

public class Lib {
List getMyList() {
return new ArrayList();
}
}

Now compile this user of the library:

import java.util.List;

public class Main {
public static void main(String[] args) {
doit(new Lib().getMyList());
}

private static void doit(List list) {
System.out.println("list is: " + list);
}
}


Ensure it all works:

> java -cp path_to_lib Main

Should output:

List is: []

Now change the Lib class to return ArrayList instead of List and
recompile just the Lib class (i.e. importantly don't recompile Main).

Now if you try:

> java -cp path_to_lib Main

you should see:

Exception in thread "main" java.lang.NoSuchMethodError:
Lib.getMyList()Ljava/util/List;
at Main.main(Main.java:5)

Cheers, Paul.

On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory  wrote:
> Can you show how older code would not function. Aside from using reflection.
>
> Gary
>
> On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:
>
>> if we are using semantic numbering would this not cause a major revision
>> change as older code will no longer function?
>>
>> Claude
>>
>> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory 
>> wrote:
>>
>> > Hi All:
>> >
>> > Updating Commons Collections' commons-parent from version 43 to 45 causes
>> > the build to fail due to the use of japicmp which reports:
>> >
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
>> > project commons-collections4: Error generating
>> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate report:
>> > Breaking the build because there is at least one incompatibility:
>> > org.apache.commons.collections4.IteratorUtils.peekingIterator(java.util.
>> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
>> > collections4.IteratorUtils.pushbackIterator(java.util.
>> > Iterator):METHOD_RETURN_TYPE_CHANGED
>> > -> [Help 1]
>> >
>> > This is caused by:
>> >
>> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
>> > return PushbackIterator.
>> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
>> > return PeekingIterator.
>> >
>> > Which are reasonable changes IMO.
>> >
>> > Does anyone object to these changes and adding exceptions to allow
>> japicmp
>> > to
>> > not fail the build?
>> >
>> > Thank you,
>> > Gary
>> >
>>
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> 
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>

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

Re: [collections] breaking changes

2018-03-29 Thread Gary Gregory

Can you show how older code would not function. Aside from using reflection.

Gary

On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:

> if we are using semantic numbering would this not cause a major revision
> change as older code will no longer function?
>
> Claude
>
> On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory 
> wrote:
>
> > Hi All:
> >
> > Updating Commons Collections' commons-parent from version 43 to 45 causes
> > the build to fail due to the use of japicmp which reports:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> > project commons-collections4: Error generating
> > japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate report:
> > Breaking the build because there is at least one incompatibility:
> > org.apache.commons.collections4.IteratorUtils.peekingIterator(java.util.
> > Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
> > collections4.IteratorUtils.pushbackIterator(java.util.
> > Iterator):METHOD_RETURN_TYPE_CHANGED
> > -> [Help 1]
> >
> > This is caused by:
> >
> > - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
> > return PushbackIterator.
> > - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
> > return PeekingIterator.
> >
> > Which are reasonable changes IMO.
> >
> > Does anyone object to these changes and adding exceptions to allow
> japicmp
> > to
> > not fail the build?
> >
> > Thank you,
> > Gary
> >
>
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [collections] breaking changes

2018-03-29 Thread Claude Warren

if we are using semantic numbering would this not cause a major revision
change as older code will no longer function?

Claude

On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory 
wrote:

> Hi All:
>
> Updating Commons Collections' commons-parent from version 43 to 45 causes
> the build to fail due to the use of japicmp which reports:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> project commons-collections4: Error generating
> japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate report:
> Breaking the build because there is at least one incompatibility:
> org.apache.commons.collections4.IteratorUtils.peekingIterator(java.util.
> Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
> collections4.IteratorUtils.pushbackIterator(java.util.
> Iterator):METHOD_RETURN_TYPE_CHANGED
> -> [Help 1]
>
> This is caused by:
>
> - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
> return PushbackIterator.
> - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
> return PeekingIterator.
>
> Which are reasonable changes IMO.
>
> Does anyone object to these changes and adding exceptions to allow japicmp
> to
> not fail the build?
>
> Thank you,
> Gary
>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

[collections] breaking changes

2018-03-29 Thread Gary Gregory

Hi All:

Updating Commons Collections' commons-parent from version 43 to 45 causes
the build to fail due to the use of japicmp which reports:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
project commons-collections4: Error generating
japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate report:
Breaking the build because there is at least one incompatibility:
org.apache.commons.collections4.IteratorUtils.peekingIterator(java.util.Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.collections4.IteratorUtils.pushbackIterator(java.util.Iterator):METHOD_RETURN_TYPE_CHANGED
-> [Help 1]

This is caused by:

- [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator signature to
return PushbackIterator.
- [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature to
return PeekingIterator.

Which are reasonable changes IMO.

Does anyone object to these changes and adding exceptions to allow japicmp to
not fail the build?

Thank you,
Gary

Re: [configuration] Java 8 types

2018-03-29 Thread Gary Gregory

Done.

Gary

On Wed, Mar 28, 2018 at 2:21 PM, Jochen Wiedmann 
wrote:

> +1
>
>
> On Wed, Mar 28, 2018 at 9:06 PM, Gary Gregory 
> wrote:
> > Hi All:
> >
> > I say it is time to update Commons Configuration to Java 8 and support
> the
> > types in java.time.
> >
> > Thoughts?
> >
> > Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [collections] breaking changes

Re: [collections] breaking changes

Re: [collections] breaking changes

[httpclient] Better user agent header?

Re: [collections] breaking changes

Re: [parent] release 46

Re: [configuration] Java 8 types

Re: [parent] release 46

Re: [configuration] Java 8 types

Re: [parent] release 46

[parent] release 46

Re: [collections] breaking changes

Re: [collections] breaking changes

Re: [collections] breaking changes

Re: [collections] breaking changes

[collections] breaking changes

Re: [configuration] Java 8 types

17 matches

Site Navigation

Mail list logo

Footer information