DaveAKing / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Modularize guava #1471

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Convert the packages 

annotations
base
cache
collect
escape
eventbus
hash
html
io
math
net
primitives
reflect
util
xml

into modules.

Most guava users are only interested in a subset of guava. A more modular 
project structure would benefit those users in the following ways.

Cutting size of dependencies
The size of the guava maven repo is roughly 7-8MB with sources and docs. This 
is way out of proportion ,if I am only interested in Optionals and 
Preconditions. Most users won't comPlain about this nowadays though, as 
bandwith and storage are cheap ;) But why be wasteful, if it is easy to avoid. 
It is also useful if your list of dependencies conveys a little about your 
intent/stance on certain problem domains. If for example I could import 
guava-base only, one might guess that I do not appreciate misuse of "null", 
whereas if the whole guava is imported, it can be any number of reasons.

Stop polluting the Classpath
Especially in team projects it is important to keep the namespaces in the 
classpath "clean" to avoid confusion, misunderstandings and to make it easier 
for junior developers or new team members to adapt to your code base.
Because guava is a general purpose library, its naming is general, increasing 
the likelyhood for names to clash with private or third-party code. So if I 
introduce guava in our project to use its concurrent utilities, my collueges 
get bombarded with choices by the IDEs autocompletion regarding "event" and 
"eventbus". This is usually not a problem because 
A. the developer is experienced enough to know what he wants,  
and
B. such errors get caught by static type checking.
But sometimes neither A nor B holds true, confusing stuff happens, flow gets 
interuppted, kittens die, bad times.

I am curious if people can think of pros/cons of a modular project architecture 
for guava itself. Faster iteration and update cycles for individual modules 
comes to mind. 

Original issue reported on code.google.com by okrylow@gmail.com on 9 Jul 2013 at 8:13

GoogleCodeExporter commented 9 years ago

Original comment by kak@google.com on 9 Jul 2013 at 8:17

GoogleCodeExporter commented 9 years ago
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08