"OSGi™ - The Dynamic Module System for Java™"
Briefly, OSGi (for "Open Services Gateway initiative") is a framework that enables dynamic loading, unloading and updating of Java modules at runtime.
Personally, I think OSGi is overkill for most applications:
While I've long been an advocate of integrating appropriate technologies,
such as SNMP (SimpleNetworkManagementProtocol
) and JMX (JavaManagementExtensions?
into business applications, it seems to me that OSGi brings too much complexity,
for flexibility and generality that is not needed in today's business applications.
From what I've seen, it's not useful unless your application really will
dynamically integrate modules written, maintained and released independently by third parties.
If you test and release you system as an integrated whole, I'm not seeing much additional value to justify the cost and complexity of OSGi.
But, of course, I could be wrong.
And increased application complexity over time, particularly should ServiceOrientedArchitecture
(SOA) become more fine-grained and integrated, could make OSGi more attractive.
I presume this is the technology in EclipseIde
which allows one to make small edits in the code of a running application and immediately see its effects. I gotta say, it is a real timesaver during development! -- IanOsgood
as its internal module system, for all of its functionality.
But I'm 99.99% sure that it does NOT use OSGi or ClassLoader
s to support Hot Code Swap while debugging.
It's a "byte code manipulation after ClassLoader
time" feature supported by only some JavaVirtualMachine
Sadly, since the JavaVirtualMachine
is not a MultitaskingVirtualMachine
, a bug in a single module can crash all the application (welcome back to a world without ProcessIsolation