com.baz.bar.foo.wombat.banana.frammitzor would it be better in
com.baz.bar.foo.wombat.papaya.frammitz.toothbrushLife is too short.
What would be so bad about having all the classes that form your application in one package? It would be nice to have some tool support for filtering views onto that soup of classes, but why have those views (no reason to have only one) hard-coded in the source files?
Further discussion lead to the conclusion that you might want to have one named package, called something like "
application.export", in which would be placed classes that are the subjects of external dependencies. You might have one other named package for your application, to avoid the
Dateproblem. But really, no-one, no-one, is doing the thing that the
com.yoyodyne.abomination.ghastly.verbose.madnesspattern is meant to enable: guarenteeing that there will be no name clashed when your runtime pulls down a bunch of classes from a random place on the network. Think of all the gateways that exist between any .jar file you might think of and your runtime environment. How many opportunities to fix any such clashes exist between finding that the name conflict exists and getting a binary deployed?