incubator-any23-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: Plugins loading
Date Fri, 17 Feb 2012 09:21:47 GMT
Hi all guys,

The ML at ASF is the best place where we can discuss ;) Also because
the more people can access to the info, then easier would be involving
new volunteers that wants to help :)

Anyway, speaking more about technical details: I had a look at the
current codebase and even if we restrict the package where performing
the plugins research, this operation has always the same complexity,
because it needs to visit the whole ClassPath

Moreover, it consumes memory: it loads ALL classes for any recognized
item that has to be passed to the filter, that checks if the current
item is a plugin or not.

Just for the record, have a look at

The Jersey approach is a little different, IIRC they did a little
trick on <>
(and is not efficient as well)

What I am proposing is something really simpler, using the
ServiceLoader <>
that would still allow dynamic definition of the plugins loaded at
runtime, but since plugins are already known at compile time, we can
drastically reduce the class loading.

There are tools as well that will help us on generating
META-INF/services metadata:

Ah, and just for the record: I prototyped a general purpose lib for
scanning the classpath, using fluent APIs, @commons, see
<> -
commons sandbox is open to all ASF committers, in the case you are
interested... ;)

All the best,

On Fri, Feb 17, 2012 at 1:14 AM, Michele Mostarda
<> wrote:
> Hi Simo,
>  we scan a set of packages that can be specified programmatically, as done
> by Jersey for example to detect providers.
> There are several optimizations that can be done like building a local
> cache to avoid a full rescan every time (for example while
> running CLI tools).  ATM the best choice is to use the more strictest
> packages as possible.
> I would like to spend some time optimizing the PluginManager, implementing
> for example a local cache based on, classpath
> files modifications. I think we could arrive to a general purpose lib
> for classpath scanning in Java (that ATM is missing AFAIK).
> Let me know when you're available for a deeper discussion about it.
> The best.
> Mic
> On 16 February 2012 23:24, Lewis John Mcgibbney
> <>wrote:
>> I'm here Simo, but of little help.. I'm nearly burnt out for the day....
>> If we can initiate a discussion it is better than nothing at all I suppose.
>> On Thu, Feb 16, 2012 at 10:21 PM, Simone Tripodi
>> <>wrote:
>> > Hi all,
>> >
>> > I started having a look at the current plugins architecture and just
>> > noticed we scan the classpath: that is the most expensive operation,
>> > because no optimization can be applied and it is always linear - that
>> > also means that more jars plugin we add, the more is memory/time
>> > consumption.
>> >
>> > There is an improvement we can apply switching over the ServiceLoader
>> > pattern, I need anyway more details about the plugins architecture...
>> > anyone available?
>> >
>> > TIA,
>> > -Simo
>> >
>> >
>> >
>> >
>> >
>> >
>> --
>> *Lewis*
> --
> Michele Mostarda
> Senior Software Engineer
> skype: michele.mostarda
> twitter: micmos
> mail:
> site :

View raw message