Yet the Jitsi developer seems to credit OSGi as an essential basis of the project. They suggest that such a modular and dynamic architecture was necessary to support so all these protocols, platforms, etc. What would you suggest as an alternative (including things that are available now, but not then)?
The parent comment here implies they rewrote it after the article was written.
I read the bit on OSGi. It seems to support interfaces, runtime loading and unloading of modules, and a way to discover modules. Java 1.0 did all that stuff natively, though JPMS adds some more capabilities, since I guess people don’t like package private, etc.
C++ also supports these things. (C does too, but you need non-standard dynamic linker constructor/destructor extensions that are available on all platforms).
I can’t think of any widely used language without support of such things.
Comments
Yet the Jitsi developer seems to credit OSGi as an essential basis of the project. They suggest that such a modular and dynamic architecture was necessary to support so all these protocols, platforms, etc. What would you suggest as an alternative (including things that are available now, but not then)?
The parent comment here implies they rewrote it after the article was written.
I read the bit on OSGi. It seems to support interfaces, runtime loading and unloading of modules, and a way to discover modules. Java 1.0 did all that stuff natively, though JPMS adds some more capabilities, since I guess people don’t like package private, etc.
C++ also supports these things. (C does too, but you need non-standard dynamic linker constructor/destructor extensions that are available on all platforms).
I can’t think of any widely used language without support of such things.