river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Kumar <bharathkuma...@gmail.com>
Subject Re: OSGi
Date Mon, 30 Jan 2017 12:29:34 GMT
Some thoughts on api design in OSGi en.


On 30-Jan-2017 3:34 PM, Michał Kłeczek (XPro Sp. z o. o.) <
michal.kleczek@xpro.biz> wrote:

> What I think Jini designers did not realize is that class loading can be
> treated exactly as any other capability provided by a (possibly remote)
> service.
> Once you realize that - it is possible to provide a kind of a "universal
> container infrastructure" where different class loading implementations may
> co-exist in a single JVM.
> What's more - these class loading implementations may be dynamic
> themselves - ie. it is a service that provides the client with a way to
> load its own (proxy) classes.
> In other words: "there not enough Jini in Jini itself".
> We have _all_ the required pieces in place:
> - dynamic code loading and execution (ClassLoaders),
> - security model and implementation that allows restricting rights of the
> downloaded code,
> - and a serialization/deserialization which allows sending arbitrary data
> (and yes - code too) over the wire.
> It is just the matter of glueing the pieces together.
> Thanks,
> Michal
> Gregg Wonderly wrote:
>> <snip>
>> I am not an OSGi user.  I am not trying to be an OSGi opponent.  What I
>> am trying to say is that I consider all the commentary in those articles
>> about TCCL not working to be just inexperience and argument to try and
>> justify a different position or interpretation of what the real problem is.
>> The real problem is that there is not one “module” concept in Java
>> (another one is almost here in JDK 9/Jigsaw).  No one is working together
>> on this, and OSGi is solving problems in a small part of the world of
>> software.   It works well for embedded, static systems.  I think OSGi
>> misses the mark on dynamic systems because of the piecemeal loading and
>> resolving of classes.  I am not sure that OSGi developers really understand
>> everything that Jini can do because of the choices made (and not made) in
>> the design.  The people who put Jini together had a great deal of years of
>> experience piecing together systems which needed to work well with a faster
>> degree of variability and adaptation to the environment then what most
>> people seem to experience in their classes and work environments which are
>> locked down by extremely controlled distribution strategies which end up
>> slowing development in an attempt to control everything that doesn’t
>> actually cause quality to suffer.
>> Gregg

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message