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.
+1 here
2012/1/10 Gabriel Roldan <groldan@anonymised.com>
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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Francesco Izzi
CNR - IMAA
geoSDI
Direzione Tecnologie e Sviluppo
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3203126609
mail: francesco.izzi@anonymised.com
skype: neofx8080
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
+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 <jody.garnett@anonymised.com> 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 GarnettOn 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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Wed, Jan 11, 2012 at 5:55 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> wrote:
+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 feel the same, but at the same time I’m worried the code will turn into COBOL pretty soon if we don’t
do some effort to modernize it.
The situation with scripting languages and the various “java successors” seems like a grand royal mess
that is not going to give us a clear successor to Java anytime soon, so we better try to get onto more
compact/modern code and try to prolongue the life of the code base as much as possible.
Of course once we adopt Guava we must make an effort to use it instead of commons wherever
possible/makes sense to get some uniformity back.
+1 on the proposal
Cheers
Andrea
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Hi Jody, thanks for the feedback.
some comments inline.
On Wed, Jan 11, 2012 at 4:24 AM, Jody Garnett <jody.garnett@anonymised.com> 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 GarnettOn 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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
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.
You drive a hard margin; there is like no way I can argue with a patch that simplifies the crazy
caching code in gt-referencing (especially since I introduced ObjectPool to remove the earlier cost caching code etc…).
Still I want to release the 8.x stream before doing anything much more to GeoTools.
We are welcome to peruse this library for GeoServer prior to that point. I also have some uDig code that used the earlier google collections library that I can fix up (and get some experience).
So you are getting two bits of feedback:
So can we put this off until after 8.x? Or if we have to we could arrange a couple day sprint to work on a github fork as a team and cut down on dependencies etc.
At the very least I don’t want to mess up 8.x with an experiment this late in the game.
Cheers,
Jody
On Fri, Jan 13, 2012 at 3:53 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:
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.You drive a hard margin; there is like no way I can argue with a patch that
simplifies the crazy
caching code in gt-referencing (especially since I introduced ObjectPool to
remove the earlier cost caching code etc..).Still I want to release the 8.x stream before doing anything much more to
GeoTools.We are welcome to peruse this library for GeoServer prior to that point. I
also have some uDig code that used the earlier google collections library
that I can fix up (and get some experience).So you are getting two bits of feedback:
- Yes - but not for GeoTools until after 8.0
- A good trade if we cut down or out the other dependencies (coming from
GeoTools)So can we put this off until after 8.x?
oh, don't get me wrong, I'm _not_ asking to push that patch to
geotools neither as-is, nor asap.
Or if we have to we could arrange a
couple day sprint to work on a github fork as a team and cut down on
dependencies etc.
yeah, that's an excellent idea.
At the very least I don't want to mess up 8.x with an experiment this late
in the game.
neither do I!
thanks,
Gabriel
Cheers,
Jody
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
+0. I like the idea but I don't know enough about guava. I'm a little more positive than Justin, perhaps a +0.5. Commons is showing its age. Maybe guava caching would have saved me some work in app-schema-resolver?
On 11/01/12 04:51, 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.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre