In
Java 9, OSGi and the Future of Modularity, Neil Bartlett and Kai Hackbarth provide part 1 of an excellent comparison of OSGi modularity and the current state of Java 9's Java Platform Module System (JPMS) modularity.
One of the most common complaints about OSGi is that it can increase
complexity for a developer. There is a grain of truth here, but people
who make this complaint are mistaking the medicine for the disease.
Modularity is not a magic dust that can be sprinkled onto an
application just before release. It is a discipline that must be
followed throughout all phases of design and development. Developers who
adopt OSGi early and apply modular thinking before writing a line of
code realise enormous gains[...]
Project Jigsaw started with a goal of being simple, but the JPMS
specification has increased enormously in complexity: the interplay of
modules with class loaders; hierarchical layers and configurations;
re-exporting requirements; weak modules; static requirements; qualified
exports; dynamic exports; inherited readability across layers;
multi-module JARs; automatic modules; unnamed modules… all these
features have been added as the need for them became clear. A similar
process happened in OSGi, just with a 16-year head start.
The article is well written and provides a clear understanding of the differences between OSGi and JPMS as it stands today. Looking forward to part 2.
No comments:
Post a Comment