Hi, Matt! I second Gary on that, there are enough preconditions to forget Java5 and focus on Java6 only.
You also have my +1 on supporting the SPI pattern on that! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Jun 3, 2012 at 6:29 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Jun 3, 2012, at 11:40, Matt Benson <gudnabr...@gmail.com> wrote: > >> I propose that we, in the immediate future, reorganize [classscan] >> into multiple modules. I fully expect that by the time we get >> everyone's input/features/alternative implementations for X/Y/Z in >> place, we will want the flexibility. I am fine with starting small, >> e.g. core/bcel modules, although I would expect that bcel might >> eventually be moved beneath another division of "scanners" or the >> like. >> >> The technical hurdle to doing this is that MetaRegistry currently >> references oacc.bcel.Cache, mapping it to its SINGLETON reference. I >> don't see that this is necessary; I would prefer that the bcel module >> provide an entry in META-INF/services. It's not even necessary that >> we upgrade to Java 6 for this; Java 6 users can use ServiceLoader >> while those using Java 5 can use whatever workalike option they prefer >> or instantiate the MetaRegistry implementation directly. In any case >> core should not depend on a particular scanning package/module. I >> don't JFDI because (a) I don't have time just at the moment, and (b) I >> like consensus. Thoughts? > > Forget java 5 and use 6. > > Gary > >> >> Matt >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
