class scanner loads classes instead of parsing byte code
Eelco Hillenius
I just read through the class scanning implementation and noticed that
it loads classes rather than reading through the byte code. The latter
has the advantage of not occupying PermGen. Is scanning byte code
(e.g. using ASM) rather than loading classes something you considered?
And if so is there any particular reason why you decided not to go
that route? One disadvantage I can see of not loading the classes is
that the matcher won't be as generic (or elegant), but I wonder how
generic it needs to be in the first place.
OT: I just implemented a class scanner myself a few days back after
finding out that the lib I used for it it initially, Reflections, is
utterly broken (besides the internals making my eyes hurt; no tests,
no javadocs, etc). I implemented this because we're switching a
project to Guice and want to have it break early when there are
problems with resolving dependencies without having to manually
register it. Imho it would be a great out-of-the-box feature to have
for Guice, and if it had that, not only would I use it, but Sitebricks
could use it as well.
Thanks,
Eelco
Dhanji R. Prasanna
Hi,
I just read through the class scanning implementation and noticed that
it loads classes rather than reading through the byte code. The latter
has the advantage of not occupying PermGen. Is scanning byte code
(e.g. using ASM) rather than loading classes something you considered?
And if so is there any particular reason why you decided not to go
that route? One disadvantage I can see of not loading the classes is
that the matcher won't be as generic (or elegant), but I wonder how
generic it needs to be in the first place.
OT: I just implemented a class scanner myself a few days back after
finding out that the lib I used for it it initially, Reflections, is
utterly broken (besides the internals making my eyes hurt; no tests,
no javadocs, etc). I implemented this because we're switching a
project to Guice and want to have it break early when there are
problems with resolving dependencies without having to manually
register it. Imho it would be a great out-of-the-box feature to have
for Guice, and if it had that, not only would I use it, but Sitebricks
could use it as well.
Thanks,
8
Eelco
Eelco Hillenius
>> I just read through the class scanning implementation and noticed that
>> it loads classes rather than reading through the byte code. The latter
>> has the advantage of not occupying PermGen. Is scanning byte code
>> (e.g. using ASM) rather than loading classes something you considered?
>
> Not really. You specify which packages to scan, so unless the user is
> deliberately polluting packages with a bunch of classes never used, then the
> PermGen issue shouldn't really arise.
I guess not. I just thought that if it is avoidable to not occupy any
memory in the first place it'd nice. But it's not a big deal.
>> And if so is there any particular reason why you decided not to go
>> that route? One disadvantage I can see of not loading the classes is
>> that the matcher won't be as generic (or elegant), but I wonder how
>> generic it needs to be in the first place.
>
> Actually, we fully support modular config *without* classpath scanning as an
> alternative mechanism. I liken it to Guice's JIT vs. module bindings:
> http://code.google.com/p/google-sitebricks/wiki/ModularConfig
Sure, I found that too. It's nice.
>> OT: I just implemented a class scanner myself a few days back after
>> finding out that the lib I used for it it initially, Reflections, is
>> utterly broken (besides the internals making my eyes hurt; no tests,
>> no javadocs, etc). I implemented this because we're switching a
>> project to Guice and want to have it break early when there are
>> problems with resolving dependencies without having to manually
>> register it. Imho it would be a great out-of-the-box feature to have
>> for Guice, and if it had that, not only would I use it, but Sitebricks
>> could use it as well.
>
> This might be a bit hard to garner support for from the Guice team. We have
> discussed it several times, and generally the consensus is that the
> module-based configuration is the big win for us and the magic of scanning
> is too much of a risk.
What kind of risk would there be though? If order matters, people
should configure that manually, and else I wouldn't know of any
potential issues other than that the whole classpath might not be
available.
> This is why in Sitebricks we fairly minimize the damage by scanning only
> specified packages (also web apps are generally organized more naturally to
> fit this) and by providing an alternative configuration mechanism based on
> modules.
Sure. What I implemented was scoped by packages as well. And don't get
me wrong, I like it a lot that Guice does not scan classes unasked.
However, I'm converting a singleton/ factory based project with
hundreds of modules to Guice, and I'd like to know early when one of
the modules is problematic (e.g. because construction fails). Manually
maintaining a list of modules that should eagerly be initialized would
not just a pita, there would be a good chance that I'd forget a few
and I might found out later than I'd like. This is where scanning and
eagerly binding modules is great.
That said, one of the things I really like about Guice is that it
doesn't make too many assumptions for me, while exposing a nice API to
do things your own way, which I in this case used to implement that
eager binding. And there's definitively something to say for keeping
Guice minimal.
Cheers,
Eelco