#93 please support java modules in the next release

[Samael]

as jericho-html doesn't include a module-info.java file, using it in an application that uses modules requires it be done based on the filename. Whilst this works, it is not the desired behaviour for modern Java applications and will actually result in a warning when used by maven:

[INFO] --- maven-compiler-plugin:3.9.0:compile (default-compile) @ javafx-app ---
[WARNING] ********************************************************************************************************************************************
[WARNING] * Required filename-based automodules detected: [jericho-html-3.4.jar]. Please don't publish this project to a public artifact repository! *
[WARNING] ********************************************************************************************************************************************

The module system has been available for years now and with 17 being the current LTS release it would be good to have the next release support modules properly.

Also as a side note; any plans to move to github? The project is far more likely to gain pull requests there

[Martin Jericho]

Hi Samael,

Thanks for raising this issue. Sorry I'm not very familiar with the java modules system so I'd appreciate if you could give me some advice and assistance.

I'm still targeting java 1.7 to maximise compatibility with older programs. In order to support modules I'd have to compile targeting java 9, right? I'm not sure whether that would mean the library doesn't work with projects targeting Java 8, which I believe is still very common. Do you know whether that would be an issue?

Have you already created an appropriate module.info.java file with the optional logging dependencies? Because of my limited experience with modules, it would be much appreciated if you could send me a zip file based on http://jericho.htmlparser.net/temp/jericho-html-3.5-dev.zip with the necessary changes.

Yes I appreciate that hosting on github would provide a much more familiar environment for potential contributors, but it's just another thing I don't really have time for at the moment.

Cheers
Martin

[Samael]

It's possible to have multi release jars but it's not trivial. You'd need to compile the existing source with JDK 7 and use JDK 9 or above to compile the module-info.java and bundle it into the same jar.

See here for some info about multi-release jars: https://nipafx.dev/multi-release-jars-multiple-java-versions/

I don't really get the desire to support JDK 7 these days, or anything below Java 11 tbh, but if it's needed perhaps it's worth continuing a 3.* branch for JDK 7/8 support and starting a new 4.* branch to target JDK 11 and above which can support JPMS.

I can put together a module-info for you when I'm next on my dev machine.

btw migrating svn to git while retaining history is fairly quick. You just need to have svn, git, and git-svn installed (ideally on Linux/Mac due to case-sensitivity). I've done it many times now and after the first one or two times it becomes a 5 min task. Worth taking a look at: https://www.atlassian.com/git/tutorials/migrating-overview

[Samael]

Sorry for the delay in looking into this. I ended up using standard Java instead of relying on Jericho. However I did checkout the source code and take a look. First off I was surprised to find it's using bazaar, if you do intend to migrate to git it should be as simple as initialising a git repo in the same directory and running brz fast-export -b main | git fast-import assuming the branch is called main. See https://jugmac00.github.io/blog/migrate-a-repository-from-bazaar-to-git/ for details.

As I'm on Linux I put together a build.sh script based on the batch file in the repo. See attached file. Note that in that script I added the path to module-info.java as well as target JDK 10 and use module path instead of classpath.

The src/java/module-info.java file I added was:

module jerichohtml {

    requires java.logging;

    // commons logging is an automatic module. This should be updated to a version that properly supports JPMS
    requires transitive commons.logging.api;

    // log4j 2.4 is an automatic module. This should be updated to a version that properly supports JPMS
    requires transitive log4j.api; // optional

    // slf4j.api 1.7 is an automatic module. This should be updated to a version that properly supports JPMS
    requires transitive slf4j.api; // todo: update slf4j to v2 and then require the correct module name: "org.slf4j"

    exports net.htmlparser.jericho;
}

This builds fine so you could use it to get going.

I'd recommend using maven to build the project. It'll makeit a whole lot easier to build and publish the project rather than relying on bespoke build scripts that are platform dependant.

[Samael]

Attaching an updated build.sh script that will also compile test sources and run unit tests

[Martin Jericho]

Hi Samuel. Thank you for doing all of this. Unfortunately this library is way down my priority list these days. I still use it in heaps of projects, and it still works well, and I still fix an occasional reported bug, but I haven't done an official release for years, and I can't see myself getting to it in the near future.
When I do eventually release a new version, I will definitely incorporate your suggestions.
Cheers
Martin