JCrete2013:Module System for Java, OSGi
| Module System for Java, OSGi | |||
|---|---|---|---|
| Convenor: Chris Richardson | |||
Participants:
| |||
Summary:
OSGI hideously complex, what to use? modules as language feature Uberto: OSGI is complicated but this is not the fault of the API Ian: OSGI is more than a module system, also event-bus etc. It tries to do too much Sven: not working on JVM-level but only on top. Jigsaw should work for any language on the JVM, not a lot is specific to Java. Basics are well understood, but splitting the JDK itself is a quit complex task which was initially underestimated Chris: Need module system for own code, don’t care for modularized JDK. Sven: package visibility stuff is part of Jigsaw. You could mix versions and more easily evolve APIs. Uberto: Relationship of Jigsaw and Maven Module-system. Do we need to depend on logical packages or on concrete modules? Kruno: How should modules be packaged? Need easy way to declare a dependency on a specific module in a specific version.
Uberto: a feature is a micro-service Richard: micro-services in multiple processes are much easier. company in China wanted to avoid JVM-per-service overhead and used OSGI. Uberto: OSGI worked well for an enterprise application requiring switching between different version of a service Chris: is Jigsaw good enough? Sven: For netbeans-based app with 1000+ modules Jigsaw probably works:
Ian, Kruno want a per-machine central repo of modules in different versions. Chris Jigsaw, does it make progress? Sven: Yes, but there were security issues which delayed everything including Jigsaw We’ll wait some time for Jigsaw to be generally available. Big companies will/should decrease their stack-upgrade cycle. Idea is: OSGI and Netbeans modules can live on top of Jigsaw, including new class path hierarchies. In 2020 javac will download dependencies instead of a build-system. Compiler dependencies will probably not be transitive. Class.forName will be broken in any module-system. One must always obtain the current context class loader. Uberto: OSGI enforces/encourages vertical modules. Infrastructure modules go horizontally across, still. Kruno: give OSGI a second chance or just wait for Jigsaw? Uberto's example: nimble-OSGI using Karaf Apache Karaf https://github.com/uberto/nimble-osgi testing bundles is cumbersome only unit and integration-testing. | |||
| Recommendations:
No recommendations provided. | |||
