JCrete2013:Module System for Java, OSGi

From WikiEducator
Jump to: navigation, search
Module System for Java, OSGi
Convenor: Chris Richardson
Participants:
  • List
  • them
  • here
  • ...
Summary:
Day 2, Session 2 - Module System for Java, OSGi - JCrete2013


Free content media streamed from Wikimedia Commons
Cc-sa.svg

Download:
Download: .ogg

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.


Chris, Kruno: OSGI is too painful.

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:

  • compiler walls
  • versioning incl. ranges
  • don’t care about artifact-format of version-declaration.

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.