I totally agree that we should not embed big jars. The Groovy distribution must remain as small as possible. We made a great effort in reducing it in the past releases, let's not kill that. Also strong -1 for Guava, which is more a framework than a library: lots of software use it and I've rarely seen a library that despite being very helpful breaks so often binary compatibility, making it a nightmare to deal with conflicts in transitive dependencies. Also strong -1 for any dependency on Scala, for almost the same reasons: strong history of breaking binary compatibility, all libraries of Scala have to be built against multiple versions of Scala. Plus it would dramatically increase the size of the distribution.
2015-10-14 17:54 GMT+02:00 Winnebeck, Jason <jason.winneb...@windstream.com> : > Pcollections looks very promising. If this is scheduled to be a dependency > for all groovy apps, I can’t imagine we could accept something like Guava, > which is very large, without at least trimming it down. The pcollections > tests don’t seem to be comprehensive, and developers normally expect a > library like collections to be *spot* on even in very obscure edge cases. > So I would have some concern about the popularity of pcollections vs. > something like Guava. Lack of activity isn’t necessarily a bad indicator – > this is the type of code you want to be absolutely perfect and never, ever, > touch again. Think about the Java 7 Collections.sort/Comparator issue > causing so many backward compatibility issues even though the new code was > well within the specification. > > > > What I don’t get about pcollections is that it promises to implement > collections interfaces like Java.util.List, but then says that “add” > doesn’t work, because you have to use plus. So, I’m not sure how it can > really be a List when none of the mutators could work. I suppose you can > implement size, iterator, contains, etc. same as Java’s unmodifiableList. > > > > Jason > > > > *From:* Shil Sinha [mailto:shil.si...@gmail.com] > *Sent:* Wednesday, October 14, 2015 11:41 AM > *To:* users@groovy.incubator.apache.org > *Subject:* Re: peristant and immutable collections > > > > +1 for pcollections for the reasons Guillaume mentioned. > > > > Drawbacks of the other options: > > > > Guava - AFAIK only provides immutable collections > > Scala - As Jochen said, Collections (along with the standard library) will > be redesigned in the near future - > https://github.com/lampepfl/dotty/issues/818 > > FunctionalJava - Data structures are only somewhat GDK friendly (they > implement Iterable, but not Map, Set or List) > > > > Alessio, is https://github.com/krukow/clj-ds the Clojure data structures > port you were thinking of? > > > > > > > > On Wed, Oct 14, 2015 at 8:02 AM, Cédric Champeau < > cedric.champ...@gmail.com> wrote: > > +1 for pcollections. Lack of activity doesn't mean lack of maturity or > lack of future activity. > > > > 2015-10-14 14:00 GMT+02:00 Guillaume Laforge <glafo...@gmail.com>: > > Also, PCollections is pretty friendly to the good old Map, Set, List > interfaces, which would be thus Groovy-friendly too, with all our GDK > shortcuts for these classes. > > > > On Wed, Oct 14, 2015 at 12:56 PM, Jochen Theodorou <blackd...@gmx.org> > wrote: > > On 14.10.2015 11:55, Guillaume Laforge wrote: > > PCollections sound like a good candidate, as you're its maintainer ;-) > (so it's easy to fix bugs, make updates, etc), it's lightweight / > standalone (not bringing odd dependencies). > > > I can even make more fine grained jars and such, yes. But I don't want to > impose a library to others for this. And while I am the maintainer, I did > not really do much yet. There is quite some work to do for this library to > be more up to date and to improve the benchmarks. I may spend that time > anyway, just with a longer time period then > > > bye blackdrag > > > > > > -- > > Guillaume Laforge > Apache Groovy committer & PMC member > > Product Ninja & Advocate at Restlet <http://restlet.com> > > > > Blog: http://glaforge.appspot.com/ > > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> > > > > > ------------------------------ > This email message and any attachments are for the sole use of the > intended recipient(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply email and destroy all copies of the original > message and any attachments. >
