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; 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.
> 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?
> 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?
> 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. We may need to duck back into GeoTools to make
that happen; but that would perhaps not be a bad thing.
--
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 (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://appdeveloper.intel.com/join)
> http://p.sf.net/sfu/intel-appdev
>
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> (mailto:[email protected])
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
