Support Java9 Platform Module System(JPMS)

[miurahr]

Motivation

languagetool does not support Java Platform Module System (JPMS).
The project only not support it, also break downstream applications/libraries to migrate Java 11, 17 and 21 and adopt JPMS .

It is because languagetool share same package among artifacts jar files, such as o.l.language package.
It is well known as split package problem.

What issue is fixed

• GitHub Issue: [jdk11] problem with dependencies [jdk11] problem with dependencies #3303
• Forum post: https://forum.languagetool.org/t/java-11-dependencies-requirements/6155

What changes

• languagetool-core

  • Escalate Contributor(s), TokenExpressionFactory class public.
    These classes are referenced from o.l.language.(Language) classes. I move these classes packages, so referenced class should be public.

• language-* submodules

  • Move modules classes to resolve a split package problem. (see. reference for details)

    • o.l.launguage to o.l.l.(lang)
    • o.l.chunking to o.l.c.(lang)
    • o.l.synthesis to o.l.s.(lang)

  • Gather MessageBundles_*.properties into language-core to resolve split package problem.
    when languagetool project want to keep a way to split bundles to submodules, Java9 provide a new way.
    There is no way to keep compatibility with both Java8 and JPMS without resolving split package problem by file moves.

• all submodules

  • Update imports to adjust for the language-* modules package changes

  • Add Automatic-Module-Name manifest entry
    manifest property Automatic-Module-Name was introduced in Java 9 platform module system, to allow migration from Java8 code to JPMS without breaking Java8 compatibility. Library users who already running on >Java9 receive benefit from the configuration.

Reference

• https://msayag.github.io/SplitPackage/
• Split package between jaxb-impl and jaxb-core prevents usage as JPMS module javaee/jaxb-v2#1168
• https://www.reddit.com/r/java/comments/9yexog/jdk_11_migration_how_to_deal_with_split_packages/

A downside

Users who use LT with following style become compile error as symbol not found.
You should rewrite it as recommended way.

bad

import org.languagetool.Language;
import org.languagetool.language.Japanese;

class Main {
static void main() {
Language language = new Japanese();
}}

good

import org.languagetool.Language;
import org.languagetool.Languages;

class Main {
static void main() {
Language language;
language = Languages.getLanguageForShortCode("ja"); // since 3.6
language = Languages.getLanguageForLocale(new Locale("en", "US"));
language = Languages.getLanguageForName("German");
}}

Status

ready for review.

Further tasks

• developer document https://dev.languagetool.org/java-api explains a way to create Language object directly. It should be rewritten with a way to compatible among versions.

languagetool-org/languagetool-org.github.io#19

• Provide compatibility layer for the user who use older language classes and want to continue their usage without JPMS support.

Other information

• The PR depends on refactor: make classes accessed from language-* to public #9407
• Reference to deal with resource bundle in Java 9 Resource Bundle Look-ups in Modular Java Applications

[miurahr]

Does LanguageTool project want to provide a Java8 compatibility option for users who stick in java8 world, and don't want to go forward to future?

[miurahr]

Does LanguageTool project want to provide a Java8 compatibility option for users who stick in java8 world, and don't want to go forward to future?

I'd like to raise it as another PR because of resolving a dependency issue with #9406 changes. After release it as SNAPSHOT version, the java8 compat module can be introduced and tested.

[danielnaber]

When the change for Language class methods visibility, I'd like just to do it?

Yes, I see no issue with that change.

[miurahr]

Partial provide of compatible classes, now work in progress.

[miurahr]

I've updated LanguageSpecificTest class to respect onlyRunCode on Disambiguation Rule Tests.

see b50d10d

It is why java8compat module test environment has all known language modules, and current test run all the languages loaded. It lead test executions too long duration, because of redundant cases.

[miurahr]

Status

Ready for review and merge.

Explanation of compatibility module

I've introduced project in languagetool-language-modules/language-java8compat that provide org.languagetool.language.(LANGUAGE) classes.

When user specified the module language-java8comat that become split package status which is incompatible with JPMS. It is why I give a name java8compat means as java9 incompatible.
Alternative naming idea is language-compat-nojpms

Core class of the compatibility module

org.languagetool.language.AbstractLanguageProxy class implements "Proxy pattern" in GoF design pattern.
All the individual language classes are inherited from it, which only have a default constructor with new language class path as argument.

Tests

Most of compatibility language classes are tested with simple test case.

[miurahr]

The change here moves all the language file package, so easily conflict other changes.
It is not pragmatic to track all the changes in master branch.

[miurahr]

rebased on current master.