Many module systems and plugin infrastructures exist in Java at the moment. IDEs typically are the well known ones, with IntelliJ, NetBeans and Eclipse all offering their own plugin systems as ways to customise the experience. However, build systems (Ant, Maven) and even end-user applications (Lotus Notes, Mac AppleScript-able applications) have the concept of being able to extend the core functionality of the application or system in question.
Arguably the most mature module system in Java is OSGi, which has been around almost as long as Java itself, first appearing as JSR 8, but more recently accepted as JSR 291. OSGi defines additional metadata in the JAR's MANIFEST.MF to indicate required dependencies on a per-package basis. This permits modules to check (at runtime) that their dependencies are met, and in addition, to permit each module to have its own private classpath (by virtue of having one ClassLoader per module). This helps, but does not completely prevent, the concept of dependency hell mentioned earlier. As with JDBC, OSGi is a specification (currently release 4.2) which has multiple open-source (and commercial) implementations. Since modules don't need to depend on any OSGi specific code, many open-source libraries now embed their meta-information into the manifest for consumption in OSGi runtimes; for those that don't, tools like bnd can post-process an existing JAR file and generate sensible defaults. Eclipse 3.0 switched to OSGi in 2004 from a proprietary plugin system; many other systems that had proprietary kernels (JBoss, WebSphere, Weblogic) have followed suit and based their runtimes on an OSGi kernel as well.