Java 11 painpoints

[hgschmie]

• conversion to modules may be necessary but will be hard

  • we use at least one jar that is in the unnamed module (jsr305), that we need to remove
  • I could not get the immutables or freebuilder annotation processors to work in tests with modules.
  • we need separate module-info files for src/main and src/test (see https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html for some guidance)

• javadocs in java 11 are a mess. The aggregation build does not work with modules and I could not figure out how to bend the javadoc plugin to my will. JPMS docs are a mess. There is some issue with --module-source-path but I could not figure this out.

  • for now, we build java 8 style javadocs

[hgschmie]

currently open bug reports:

• https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-767
• https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-768
• https://github.com/codehaus-plexus/plexus-languages/pull/164

all of those need to be fixed to make progress with JPMS and javadoc

[stevenschlansker]

Sounds like we should split out test utilities from test cases, and have the former exist as a library jar, and the latter test-jars not be used as a dependency ever.

[hgschmie]

• https://issues.apache.org/jira/browse/SUREFIRE-2190

[hgschmie]

Sounds like we should split out test utilities from test cases, and have the former exist as a library jar, and the latter test-jars not be used as a dependency ever.

The module system supports a setup where the test code is in regular jars and the main artifacts are JPMS modules just fine. Maven tooling is simply buggy. I am fairly certain that fixing the plugins is doable and then we can ship fully JPMS enabled artifacts with minimal impact to our development process.

I refuse to start playing games with reshuffling code from test to regular artifacts (which then in turn would be their own JPMS modules, which in turn would need to use different packages (because JPMS modules must not overlap), which in turn changes visibility rules for our code (package private goes out of the window, we now need to have additional public classes, which we then mask out in the module-info files with exports xxx to module-a, module-b etc. It is all very unpleasant. I prefer to fix the tooling once and keep our code organized.

Right now, I think we will stick with Automatic-Module-Name for a bit longer.

[hgschmie]

I have a workaround for https://github.com/codehaus-plexus/plexus-languages/pull/164

[hgschmie]

https://github.com/opentable/otj-pg-embedded/pull/184 needs to be merged and resolved, otherwise we can not publish the otj test code.

[hgschmie]

https://issues.apache.org/jira/browse/SUREFIRE-2191 - stops tests in jdbi3-testing from working. No resolution or workaround.

[hgschmie]

https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-767 - patch has been applied, should be in the next release

[hgschmie]

https://issues.apache.org/jira/browse/MJAVADOC-769 blocks generating java 11 compatible javadocs even with the automatic module names.

[hgschmie]

Fix for MJAVADOC-769 proposed: https://github.com/apache/maven-javadoc-plugin/pull/227

There is a workaround as well, by building the guice module against guice 7.0.0, not 5.1.0

[hgschmie]

closing this issue in favor of tracking things here: https://github.com/jdbi/jdbi/blob/master/JPMS-SUPPORT.md