Add basic Java 9+ module info

[cowtowncoder]

As per ealier PR #145. Seems to load ok with JDK 7 and JDK 8 too but need to verify if need to move under version/9 for tooling or something.

[cowtowncoder]

@GedMarc is there anything you'd want changed here?

[GedMarc]

Databind :

module com.fasterxml.jackson.databind {
    uses java.nio.file.spi.FileSystemProvider;

    uses com.fasterxml.jackson.databind.Module;

    exports com.fasterxml.jackson.databind;
    exports com.fasterxml.jackson.databind.annotation;

    exports com.fasterxml.jackson.databind.ser.std;
    exports com.fasterxml.jackson.databind.deser.std;

    exports com.fasterxml.jackson.databind.module;
    exports com.fasterxml.jackson.databind.introspect;
    exports com.fasterxml.jackson.databind.cfg;
    exports com.fasterxml.jackson.databind.type;
    exports com.fasterxml.jackson.databind.ser;
    exports com.fasterxml.jackson.databind.ser.impl ;
    exports com.fasterxml.jackson.databind.jsontype;
    exports com.fasterxml.jackson.databind.util;

    exports com.fasterxml.jackson.databind.deser;
    exports com.fasterxml.jackson.databind.deser.impl;
    exports com.fasterxml.jackson.databind.jsonFormatVisitors;
    exports com.fasterxml.jackson.databind.node;
    exports com.fasterxml.jackson.databind.jsontype.impl;

    requires transitive com.fasterxml.jackson.core;
    requires transitive com.fasterxml.jackson.annotation;

    requires java.xml;
    requires java.logging;

    //Optionals
    requires static java.sql;
    //TODO The JDK 7 Impl, Think about getting rid of this
    requires static java.desktop;
}

[GedMarc]

Core :

module com.fasterxml.jackson.core {
    exports com.fasterxml.jackson.core;

    exports com.fasterxml.jackson.core.type;
    exports com.fasterxml.jackson.core.io;
    exports com.fasterxml.jackson.core.util;
    exports com.fasterxml.jackson.core.base;
    exports com.fasterxml.jackson.core.json;
    exports com.fasterxml.jackson.core.filter;
    exports com.fasterxml.jackson.core.format;
}

[GedMarc]

Guice Addon (Make sure to use 4.2.2 of Guice! - asm and cglib updates)

module com.fasterxml.jackson.module.guice {
    exports com.fasterxml.jackson.module.guice;

    requires com.fasterxml.jackson.core;
    requires com.fasterxml.jackson.databind;
    requires java.logging;

    requires com.google.guice;
    requires com.fasterxml.jackson.annotation;
    requires javax.inject;
}

[GedMarc]

DateTime Module

module com.fasterxml.jackson.datatype.jsr310 {
    exports com.fasterxml.jackson.datatype.jsr310;

    provides com.fasterxml.jackson.databind.Module with com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;

    requires transitive com.fasterxml.jackson.databind;
}

[GedMarc]

DataTypes Module

module com.fasterxml.jackson.datatype.jdk8 {
    exports com.fasterxml.jackson.datatype.jdk8;

    requires com.fasterxml.jackson.databind;

    provides com.fasterxml.jackson.databind.Module with com.fasterxml.jackson.datatype.jdk8.Jdk8Module;
}

[GedMarc]

Named javax.inject library (tck is finalized and the owner of the actual maven project is missing ;)

In order to use JLink every module used has to be strictly named (e.g. have a module-info.class)

<dependency>
    <groupId>com.jwebmp</groupId>
    <artifactId>javax.inject</artifactId>
    <version>1.1</version>
</dependency>

[GedMarc]

Oh, please don't move under version 9, rather just leave it in its correct place src/module-info.class

Has to do something with the jrt mapping or somethings like that

[cowtowncoder]

@GedMarc questions on databind:

1. Why are uses java.nio.file.spi.FileSystemProvider; and uses com.fasterxml.jackson.databind.Module; needed? (I assume second one is for Module auto-registration, but first one?)
2. Which part of Java 7 support needs requires static java.desktop;?

also: I assume you used a tool to derive these; is it just using Moditect to output them or something else? Mostly asking as I am thinking of adding module info for some other projects like Woodstox, Aalto and java-classmate, and esp. for first 2 I'd like generation without moving immediately past Java 8.

[GedMarc]

No no, I type line for line - you can't "autogen" these ;) That's why it takes so long, creating scenarios... but it's also how you find things like this ;)

1) SPI, these are the ServiceLoader.load() that you use. You cannot use the .load method to call for services not "used by" that module - Both are important. 1a) You use the FileSystemProvider over here : Line 74

OK, java.desktop was for one of the classes used from the awt stack - Got to go hunting for it brb

[GedMarc]

2) java.desktop has java.beans package :

[GedMarc]

3. For this, honestly, I take the start from nothing approach and see what breaks, and go from there.

I wouldn't auto-gen it, otherwise they make it more strict in a Java later on - the only reason it is so strict is because people were auto creating their "OSGi" into the manifest file and everything was open anyway, so OSGi quite simply just didn't work, because of auto gen... Everything is exported so whats the point.

[cowtowncoder]

Oh. Thanks, wondering if I should simply drop that silly FileSystemProvider. Odd wrt Java beans but it is what it is.

As to auto-generating: I don't mean auto-generating and blindly using it (which I agree is dangerous), but actually auto-generating as starting point. I used that with aalto-xml (took a while to get it right due to bit gnarly exceptions Moditect throws or re-throws) and it was pretty useful, including finding SPI stuff to expose.

A counterpoint wrt OSGi is that NOT generating these automatically meant that sometimes refactoring (adding new package) lead to dysfunctional OSGi bundle. Ideally there would have been integration tests of sort but that's where my not-ever-really-using-OSGi did not help.

[GedMarc]

Purely opinion :) I'm a bit strong of them, working on it.

Ahh the skeleton to the bone approach :) I do that with things like JPA, netbeans somehow the best at it. For this though, out of the last 2 years, bottoms up for me. Only what is getting used, not what I think should be.

The rest is OSGi and the modular system mini-rant ;)

OSGi never really sat well with me, was always too easy to work around, The dysfunctional modules according to the spec is still actually a thing, I couldn't believe it, What's the point of this spanking new system!!! I write a new module and oh crap, i have to expose require and open this, provide and use this, then still somehow adhere to encapsulation sigh and enforce package encapsulation as well. WTF.

So after a while blood sweat and tears, I finally get to... JLink and JMod - I believe are the solutions to this though? You cannot build a JLink distributable if all the modules cannot interoperate properly, it's actually beautiful. And you can't "deploy/distribute" anymore without a JLink runtime xD And you can't plug modules in, after they've been processed by the JVM (interestingly hibernate injects jandex btw, very pretty code - in a premain (https://github.com/hibernate/hibernate-demos/blob/master/java9/custom-jlink-plugin/agent/src/main/java/org/hibernate/demos/jlink/agent/JLinkPluginRegistrationAgent.java)

If you take a project from conception to distribution in JPMS, I think only then does it make sense to be honest. There is no more such things like copy and paste JAR into a folder, containers are pointless and have no more power (at all), field injections are thrown out, now use properties and the new method naming pattern (good call throwing E.E. out oracle, no like legitimately), no more wars, sars, hars, ears. And then xD to top it all off. There is no such thing as a "JRE" anymore (well not in the JDK8 and less sense in anycase)

It's a lot of back and forth to try and deploy something, but when you do, goodness me. It's tiny, super ultra lightning babe fast, and the footprint is tiny tiny.

[cowtowncoder]

Interesting. Not sure I fully appreciate things yet, but the part about end-to-end makes sense, and is about the only thing OSGi could never provide, given they are ... not Oracle. And I am somewhat interested in getting to package full Java apps/services, wherein modular JDK (less fat) makes sense. And maybe allows finally shedding the load of (IMO very) stupid decision of JDK to bundle implementations of so many JSRs/JCPs (over just APIs, if even them).

[cowtowncoder]

@GedMarc Looks like 3 out of 6 base modules (afterburner, guice and osgi) work ok; and one is sort of obsolete (Paranamer). But I am having some trouble with jaxb, due to (allegedly) missing javax.activation. Obvious choices via https://mvnrepository.com/search?q=activation do not seem to work at least for Moditect generation. I guess I'll need to try to cobble that one together more manually.

[cowtowncoder]

N/m, remember that you had provided the module-info settings earlier, so was able to use those. Also realized that module-info generator by Moditect plug-in is way pickier than part that just parses and includes.

Then again the real test would be trying to use modules thus built...

[GedMarc]

Ahhh, Yes Activation now part of jdk, no need to include any libraries in jdk 11 but for jdk 8 you do have to up the version a bit :) JAXB 2.3 and activation -

<javax.activation.version>1.2.0</javax.activation.version>

  <dependency>
                <groupId>javax.activation</groupId>
                <artifactId>javax.activation-api</artifactId>
                <version>${javax.activation.version}</version>
            </dependency>

I found for spring you must make them all optional on the dependencies (the version is super old in the pom but it still works fine when you use spring 4 or 5).

I went through pretty much all the addon modules, I do have the module-info's for (close to) all of them, just the ones that I've tried and tested thoroughly I posted earlier -

If you get stuck let me know :)

[cowtowncoder]

@GedMarc Ok: almost done with initial versions of module-info, but hit one odd problem. So, jackson-module-jaxb-annotations builds, but attempting to generate module info for JAX-RS modules (jackson-jaxrs-providers) fails with:

[ERROR] Failed to execute goal org.moditect:moditect-maven-plugin:1.0.0.Beta2:generate-module-info (generate-module-info) on project jackson-jaxrs-cbor-provider: Execution generate-module-info of goal org.moditect:moditect-maven-plugin:1.0.0.Beta2:generate-module-info failed: Module java.xml.bind not found, required by com.fasterxml.jackson.module.jaxb -> [Help 1]
[ERROR] 

when I try to use Moditect to generate module-info.java. I have tried adding Maven dependency, but am also wondering if line from JAXB annotations module

requires java.xml.bind;

is or is not right -- there seems to be some confusion wrt that and javax.xml.bind.

So I am wondering if you could help figure this out. I suspect it either comes down to wrong dependency in JAXB-annotations module, or having to (temporarily) add some other direct dependency from JAX-RS providers.

[cowtowncoder]

Hmmh. Ok, so one way to cheat that might work... temporarily commenting out JAXB API dependency from JAXB-annotations module. Will see where that leads.

[GedMarc]

Will take a look when I get a moment, usually it's updating to 2.3, will pull master branch and see. I think it's an include and exclude per jdk config in the pom

On 3 Apr 2019 06:05, Tatu Saloranta notifications@github.com wrote:

Hmmh. Ok, so one way to cheat that might work... temporarily commenting out JAXB API dependency from JAXB-annotations module. Will see where that leads.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/FasterXML/jackson-annotations/pull/151#issuecomment-479329829, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFHm2VN-yiuxAQfxNd2RG8M7mlOuGY2Bks5vdCimgaJpZM4bdxYB.