Module system
From APIDesign
(Difference between revisions)
Line 1: | Line 1: | ||
Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | ||
+ | |||
+ | |||
+ | === A bit of math === | ||
+ | |||
+ | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management on module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. |
Revision as of 08:02, 2 September 2009
Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. Java users can choose from OSGi, NetBeans Runtime Container or possibly mix them together.
A bit of math
Module system design needs to face some tricky (e.g. NP-Complete) issues. Especially complex is management on module dependencies as described at LibraryReExportIsNPComplete. This can have various solutions (like LibraryWithoutImplicitExportIsPolynomial), but it also shows why good API design skills are needed and why BackwardCompatibility is important.