Module system
From APIDesign
(→A bit of math) |
|||
| Line 6: | Line 6: | ||
=== A bit of math === | === A bit of math === | ||
| - | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management | + | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management of 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. |
=== The need for Common Ground === | === The need for Common Ground === | ||
Revision as of 09:12, 27 October 2009
Specification and also an implementation for packaging, managing dependencies, deploying and executing applications composed from pieces/modules. Java users can choose from OSGi, NetBeans Runtime Container or possibly mix them together.
In case one cares more about the build than execution, then have a look at Maven. In case your primary domain is packaging, then you are probably seeking for RPM or Debian solutions.
A bit of math
Module system design needs to face some tricky (e.g. NP-Complete) issues. Especially complex is management of 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.
The need for Common Ground
Do you wonder why certain people think Ruby is better than Java? Do you think it is due to duck-typing? Due to having closures? Wrong, it is because Ruby has Gems. Listen to following screencast to get convinced that Java needs such common ground too. See it with your own eyes in action.
<comments/>
Follow
