+0.
The guava library looks beautiful, no question there, and there is a lot of
hype around it at the moment on all the java blogs. But as I mentioned
before, and as jody mentioned i don't love the idea just lumping on another
utility library. Obviously it leads to much nicer code, and has some
functionality we don't have now but without a concrete problem it solves i
don't see that as justification enough alone. It is already enough of a
maze trying to look up the right utility class to use when you have to do
something, this will make it worse.
Also, what happens when guava becomes outdated? For instance what if a new
snazzy library comes out that makes coding on later java versions
(7,8,etc...) much nicer. Will we add it and have then commons, guava, and
it?
Anyways, sorry, this is not a negative vote, just an explanation of
a slightly non positive one :) I would actually be more in favor of a lower
level effort at the geotools level to replace commons with guava. Obviously
though that is a larger effort and by no means meant to block the proposal.
-Justin
On Wed, Jan 11, 2012 at 12: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; 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
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
