OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [collections] breaking changes


I have been of 2 minds on this.  On one side I think we move forward, bump
the number.

on the other side is the part of me from my $dayjob that has to deal with
new versions and security alerts and make it all run on Java 6 (I'll not
bore you with the details here).

Having flopped back and forth on this in my mind I finally come down on the
side of keeping the changes bumping the version number.  We should not stop
progress for fear of breaking some code (eggs and omelets) as long as we
are clear and clean.  Those that need new functionality but can't take all
the changes a re free to recompile as they need; as we will do at my
$dayjob.

+1 bump the number and keep the functionality.
+2 if we clearly document where it breaks from earlier version ;)

Claude

On Sat, Mar 31, 2018 at 2:08 AM, Dave Brosius <dbrosius@xxxxxxxxxxxxxxxx>
wrote:

> i'm not sure i follow, don't we already have breaking changes for which
> we've decided to change bump the version?
>
>
>
> On 03/29/2018 11:00 PM, Paul King wrote:
>
>> 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 <paul.king.asert@xxxxxxxxx>
>> 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/codehau
>>> s/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 <T> List<T> withDefault$$bridge(List<T> self, Closure<T>
>>> init) {
>>>      return withDefault(self, init);
>>> }
>>>
>>> to match the original methods we are duplicating, e.g.:
>>>
>>> public static <T> ListWithDefault<T> withDefault(List<T> self,
>>> Closure<T> init) {
>>>      // ... code here ...
>>> }
>>>
>>> Cheers, Paul.
>>>
>>> On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka <peter@xxxxxxxx> 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 <sebbaz@xxxxxxxxx> 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 <garydgregory@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Yep, that's no good. I'll revert.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King <
>>>>>> paul.king.asert@xxxxxxxxx>
>>>>>> 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 <
>>>>>>> garydgregory@xxxxxxxxx>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Can you show how older code would not function. Aside from using
>>>>>>>>
>>>>>>> reflection.
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Thu, Mar 29, 2018, 09:03 Claude Warren <claude@xxxxxxxxx> 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 <
>>>>>>>>>
>>>>>>>> garydgregory@xxxxxxxxx>
>>>>>
>>>>>> 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
>>>>>>>>> <http://like-like.xenei.com>
>>>>>>>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>>>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren