I've recently been attempting to understand how Guice works. My initial impression on looking at com.google.inject.internal is "Wow, what a lot of classes, this is quite daunting!".
On further inspection, it turns out that about a third are general utility common code. I would like to propose that such classes move to com.google.inject.internal.util (or similar) to render the package containing the core internal logic of Guice less crowded. My initial list of candidates to move is: AbstractIterator.java AbstractMapEntry.java AsynchronousComputationException.java Classes.java Collections2.java ComputationException.java CustomConcurrentHashMap.java ExpirationTimer.java FinalizablePhantomReference.java FinalizableReference.java FinalizableReferenceQueue.java FinalizableSoftReference.java FinalizableWeakReference.java Finalizer.java Function.java Hashing.java ImmutableCollection.java ImmutableEntry.java ImmutableList.java ImmutableMap.java ImmutableSet.java Iterables.java Iterators.java Join.java LineNumbers.java Lists.java MapMaker.java Maps.java NullOutputException.java ObjectArrays.java Objects.java Preconditions.java Sets.java SourceProvider.java StackTraceElements.java Stopwatch.java Strings.java ToStringBuilder.java UnmodifiableIterator.java The vast majority of these can be moved with nothing more than package and import statement changes. The exceptions are: * Classes and Stopwatch would have to change from package-private to public - I'd classify that as an acceptable compromize for more readable code, given that all of the others mentioned above are already public anyway. * Finalizer and FinalizableReferenceQueue have string literal and javadoc references to classnames that need fixing up. You would expect that there would be no dependencies from the utility package to the rest of Guice. With the above moves, this is nearly the case: the exception is that StackTraceElements and LineNumbers refer to some methods in MoreTypes. Proper separation could be attained by separating MoreTypes into the parts that deal with Guice TypeLiterals and the parts which deal with pure JDK classes. Please let me know what you think of this idea, so that I know whether it's worth me working up an actual patch. Max.
signature.asc
Description: OpenPGP digital signature
