Hi Jody, thanks for the feedback. some comments inline.
On Wed, Jan 11, 2012 at 4:24 AM, Jody Garnett <[email protected]> wrote: > Wow that is a detailed proposal; indeed I started this email as notes (and > by the time I got to the bottom of the page you had answered most of my > questions). > > From the proposal: > > Basic utilities: Make using the Java language more pleasant > Collections: Guava's extensions to the JDK collections ecosystem. These are > some of the most mature and popular parts of Guava. > Caches: Local caching, done right, and supporting a wide variety of > expiration behaviors. > > I am a bit concerned we will have too many of these; Could be. Just as an example, and with absolutely no intention to finger point to anyone, we have a bunch of json libraries too, but I'm sure each one was either carried over by something else or chosen because solved something that the existing ones didn't. >we already use several > "commons" libraries for the same purpose. Is there any chance we could > replace our use of commons collections and so forth? We do use use commons > ObjectPool as a cache for example in geotools. Here's a patch the replaces commons-pool in on GeoTools modules/library/* <https://github.com/groldan/geotools/commit/7399772222d603916c1919a36b09f09ad25d6f72> It's surely not perfect, referencing is a scary beast and I made it in a rush. But it saves us 840 lines of code (counted with cloc), and IMHO has the potential to make the module less scary. Besides we get to use a caching library for caches instead of a pooling library. > > Functional idioms: Used sparingly, Guava's functional idioms can > significantly simplify code. > Concurrency: Powerful, simple abstractions to make it easier to write > correct concurrent code. > > I have had good luck with the java 5 concurrency classes; I assume these > have better collection integration? honestly I can't really say. Didn't manage to make use of them yet. Check the links for the stuff you're interested in :) > > Strings: A few extremely useful string utilities: splitting, joining, > padding, and more. > Primitives: operations on primitive types, like int and char, not provided > by the JDK, including unsigned variants for some types. > Ranges: Guava's powerful API for dealing with ranges on Comparable types, > both continuous and discrete. > > We have rolled our own based on JAI; is Guava is a replacement? May be, I don't have all the answers nor the energy to carry it over alone. I'd be psyched to help in the process though. > > I/O: Simplified I/O operations, especially on whole I/O streams and files, > for Java 5 and 6. > > We have some DataUtilities file filter stuff it would be nice to get rid > of. > > Hashing: Tools for more sophisticated hashes than what's provided by > Object.hashCode(), including Bloom filters. > EventBus: Publish-subscribe-style communication between components without > requiring the components to explicitly register with one another. > Math: Optimized, thoroughly tested math utilities not provided by the JDK. > > Nice. > > Well I really like that set of capabilities; while it would represent an > increased learning curve to work on GeoServer - it would be a win if we > could remove a few more dependencies. And also if we remove some more custom code (like the different kind of ObjectCaches in the patch above). Perhaps guava gets so used by the wider java crowd that it actually lowers the learning curve, I don't know. We may need to duck back into GeoTools > to make that happen; but that would perhaps not be a bad thing. Hope so. Thanks again for the feedback. Let me know if there's anything missing or that needs more clarification for the GSIP (although I promise I'm done with long code examples like the above, I very much welcome the discussion and questions). Cheers, Gabriel > > > -- > Jody Garnett > > On Wednesday, 11 January 2012 at 6:51 AM, Gabriel Roldan wrote: > > Hi all, > > I put together a proposal for the introduction of Google's core guava > library as a GeoServer dependency: > > <http://geoserver.org/display/GEOS/GSIP+68+-+Introduce+GUAVA+library+as+dependency> > > Feedback much appreciated. > > Gabriel. > > -- > Gabriel Roldan > OpenGeo - http://opengeo.org > Expert service straight from the developers. > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
