On Thu, Feb 16, 2012 at 2:49 PM, Mansour Al Akeel <mansour.alak...@gmail.com > wrote:
> > > > 2012/2/16 Nicolas Lalevée <nicolas.lale...@hibnet.org> > > > > implementation are, but a 1s launch (bash script and jvm launch included) > > would be to too long for me. > > > Agreed. > > And this is why I suggested java plugin framework in a previous email > (assuming it is faster than OSGI). I read that there are some fast OSGI > implementations. Didn't try anything yet. > I'm neither an OSGi fan or bigot, but in my experience OSGi itself, as a specification, does not imply poor performance. There are some aspects of the OSGi runtime package wiring specification that are NP-complete, but this typically doesn't hurt real performance unless you have a system of thousands of bundles like Eclipse. I would hope something like Ant never got that far. In particular, loading the actual OSGi runtime is very fast, on the order of milliseconds. Keep in mind that the original OSGi runtime environment was (and still is) embedded systems with limited memory and CPU. How the application is designed, such as the degree of modularity, is ultimately the biggest determinant of performance. To that end I don't know if we could compare an (as yet unknown) standard Java modularity system) to OSGi, but I would be surprised if the native system was significantly more performant--unless it gave up some of the invaluable features that OSGi provides. As an aside, and speaking of Eclipse, you would want to keep in mind how to embed an Ant containing an OSGi runtime inside Eclipse. This isn't impossible, but it could lead to some interesting classloader hierarchies. Rich
