This sounds like a great idea. I think it'd be worth doing, with one caveat: It's only worth it if *no more classes become public.* It's already a shame that the internal package needs to expose some things as public in order for other packages to use them, which leaks some internal bits of Guice... a number of projects are already using the internal classes, and I'd hate to expose even more of them.
If it's doable without these things becoming public, I think our best bet is to try and solidify a 3.0 and *then* make the change, similar to how 2.0 got pushed last time and then the internals were refactored. sam On Tue, Jun 29, 2010 at 3:54 AM, Max Bowsher <[email protected]> wrote: > On 29/06/10 01:27, Sam Berlin wrote: > >> I believe that >> Guice SVN is ready as-is for a 3.0 release, but if you are all able to >> glance at any open issues and point out major ones that can be solved, >> it would be appreciated. >> > > I made a suggestion on this mailing list some time ago entitled "Move > internal utility code to separate package?" to which the response was > somewhat lukewarm, and included some measure of "not until a major release". > > Given that you're now heading into a major release, I'd really like someone > to give me the answer I'm looking for, namely either "Yes, it's worth you > working up a patch for this" or "No, we're not doing it." > > Max. > > =========== Original email copied below =========== > > 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. > > > > -- > You received this message because you are subscribed to the Google Groups > "google-guice-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-guice-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-guice-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
