Util Packages Are Evil
util, common, base, infrastructure, model, framework names sounds great but are too generic as package names. Such names are un-cohesive by nature. Because of the abstract naming, they end up being a "kitchen sink". All inconvenient classes are placed in the "util" packages what makes such packages bloated, the classes harder to find and the application harder to maintain.
Instead of naming a package util, name it after it true responsibilities e.g. logging, monitoring etc. It will keep the packages small and the application easier to maintain.
[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 420 in, chapter "Pragmatic Java EE Architectures"]
Yep, I agree, but sometimes it isn't really trivial to create semantic package name. So that It needs time to realize real semantic value of some class.
Posted by Oleg Tsarev on December 21, 2012 at 01:24 PM CET #
I ve thought about it, but I don't agree. There is a reason for putting things into a util package. e.g. your whole application should use the same date format. I would put a class into the util package named DateFormats containing maybe "formatDate" and "formatTime".
A package date would just make it harder to find other packages that are important to the core function of my software.
Classes stored in util packages should just contain static methods and be stateless.
Later on you may put your util package into a own maven module, that you don't have to copy every class you need into your new project.
Posted by Simon on December 21, 2012 at 02:32 PM CET #
@Simon,
why you don't just call the package "dates" then? :-)
Thanks for your feedback--it is probably a start of a longer discussion :-)
thanks,
adam
Posted by Adam Bien on December 21, 2012 at 03:22 PM CET #
as a subpackage of util or on a lower package level?
Posted by Simon on December 21, 2012 at 04:08 PM CET #
I agree package names have to be named in a semantic way. A different thing is to find a name for a module. It is perfectly valid to have a unique jar file that can be used not only across the application but also across applications. Of course depending of the granularity of that module sometimes it could be called utils.jar.
Posted by Gerson on December 21, 2012 at 04:41 PM CET #
Taking from your examples, isn't "date", or "logging" just a more detailed description than "util" ?
If that's so this would be a discussion more on the benefits of being more descriptive or less descriptive in package naming...
I think although descriptiveness should be encoraged, sometimes having a more abstract package organization can be usefull, just like when you describe an architecture you don't want to focus on details, so to in package naming, having a sort of "meta-classification" can be usefull, for example in:
(...).util.date
(...).util.map
having the "util" part adds to the descriptiveness of what's in the packages (imo).
Nevertheless I fully agree that "common", "util" and so on can be design smells when abused :-)
Posted by Pedro on December 21, 2012 at 07:24 PM CET #
I think those package names are good to structure your modules into smaller ones but not to contain any implementations or classes. Also to bundle source which won't fit into a module could be organized that way (e.g. For logic which handles the integration of those modules...).
E.g.
com.mydomain.mymoduleA.entity
com.mydomain.mymoduleA.controller
com.mydomain.mymoduleB.entity
com.mydomain.mymoduleB.controller
com.mydomain.common.service
com.mydomain.common.entity
Posted by Markus on December 21, 2012 at 09:26 PM CET #
I just give you an example:
structure of a client part of a media db my way:
-api
--cache
--connector
--entity
-clipboard
-jsf
--converter
--wrapper
--handler
--validator
--view
-notifier
-util
structure of a client part of a media db your way:
-api
--cache
--connector
--entity
-clipboard
-date
-email
-name
-image
-jsf
--converter
--wrapper
--handler
--validator
--view
-notifier
-url
-zip
Ok, let's see why I prefer my way. In my case I see where my core functions are. The notifiers, clipboard and the api with its connectors. There are 2 more packages. jsf, so just any ui crap. util, every stuff that just supports my business logic.
When I've to extend my image utils or sth else it ist harder to find, but for the time I'm working on the business logic the 5 packages won't disturb me.
Posted by Simon on December 21, 2012 at 11:39 PM CET #
You have just given a reason for me not to buy your book.
Posted by Nugie on December 23, 2012 at 05:45 PM CET #
Being part of a team that provides an integration framework, and being the developer responsible for maintaining a "util" module, I have to admit that such packages and modules become "kitchen sinks", junk rooms, and garages for everything from collections to formatters, and everything else. It starts out as being something that every other module needs to import, but in the end most modules only use a small number of the dozens of utilities. I've been guilty of perpetuating this "kitchen sink" behavior, and I've decided I must repent. :)
Posted by Robert Thornton on December 23, 2012 at 11:32 PM CET #
Hi Adam,
I use util packages for classes that "should be coming from somewhere else", but they aren't (either because they don't exist in the JDK or because I would have to drag too many dependencies from another library). That's what makes them "cohesive".
For example, in most of the libraries I developed, I had a util package with NullUtil.equals(Object, Object) and now I will drop it with more usage of Java 7. Some of them I have now in a shared library:
http://epics-util.sourceforge.net/apidocs/index.html
but the gist is the same: it's classes that (in an ideal world) I would find already there in the JDK.
So: I may agree you "in principle" (e.g. they should not exist in the JDK), but not in practice. :-)
Gabriele
Posted by Gabriele on December 25, 2012 at 09:52 PM CET #
@Nugie,
you mean: this post is the condensed wisdom of the http://realworldpatterns.com ? :-)
I don't think I covered the util-packaging in the "Real World Java EE Patterns Book" book.
Btw. you don't have to buy the book, you can lend it for free :-)
thanks for your comment!,
adam
Posted by Adam Bien on January 07, 2013 at 12:01 PM CET #