Jigsaw support

[lpandzic]

FasterXML/jackson-databind#1536

[cowtowncoder]

I assume changes needed for parent too? Or is this just to fix it for specific CI auto-build or something?

[lpandzic]

I've used it to build locally, I've reverted the change.

[cowtowncoder]

Presumably no way to indicate "just include all"? (perhaps with potential blacklisting of things NOT to export)

[lpandzic]

Nope, every package and subpackage needs to be explicit.

[cowtowncoder]

As with annotations changes, would be good to have bit of explanation of changes.

[cowtowncoder]

Actually I think there is a problem here... does this require java 9 to compile everywhere?
I might be ok with Travis requiring that, although ideally we would build on supported platforms.
But requiring java 9 for local work is a no go for me personally. Java 8 might be ok, but 1.8.0_122 seems to barf on module-info.java.

[lpandzic]

Actually I think there is a problem here... does this require java 9 to compile everywhere?

Yes it does, for the very reason you mentioned. This is the reason why they added enhanced support for backwards compatible compiling with the release flag of the javac (and maven compiler).

[cowtowncoder]

Ok. Unfortunately this means that until such that I will start using Java 9 tools myself, these changes can not be done. I expect it will take quite a while until this happens.

And for annotations, jackson-core, there may be even bigger problem: since java 8 javac does not allow compilation to earlier compatibility levels (as far as I have read), this would seem to require baseline of java 8 for anything with Jigsaw.

[cowtowncoder]

FWTW, looks like "Module name" might be the only thing we can do pre-Java-9 migration:

http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html

[MaSven]

Is there any update in providing jigsaw support?

[cowtowncoder]

Module name has been added, no other on-going plans for changes at this point.
(so all components do have module name metadata added for minimal level of identification).

Jackson 3.0 will require Java 8 baseline, but build needs to remain Java 8 as well at least initially.
Last I checked tooling was the challenge so that Oracle only saw fit to allow building module metadata with Java 9 tools. If there are Java 8 tools (Maven modules), contributions for other improvements would be welcome.

[MaSven]

As i understand it correctly java 9 can build a multi version build. So that it can still run on java 8,7 and so on. Also the tools eg. Maven and IDEs are now mature enough for this. If wanted i could try to do an fork an do some work towards it. So it will be finished for java 11 the next lts version this year.

[cowtowncoder]

Java 9 building earlier versions is useful, but I really do want to keep Jackson buildable on Java 8 for now, and have no plans to move on Java 9 tooling yet (as a pre-requisite).

[jwilmoth]

With Java 8 reaching it's original EOL schedule for updates a couple of days ago (extended to Jan)(http://www.oracle.com/technetwork/java/javase/eol-135779.html) moving to Java 11 is definitely making more and more sense for business applications. Since JLink doesn't support the automatic module name bridge it would be nice to get the module-info class available one way or another. Would the core project entertain publishing modules using the process described on https://github.com/codetojoy/easter_eggs_for_java_9/tree/master/egg_34_stack_overflow_47727869 as atleast an interim solution?

[cowtowncoder]

@jwilmoth Fortunately beyond Oracle's EOL, Java 8 will be supported for years (5 years...) by other vendors (Red Hat). And if all goes well, by not-for-profit entity as well (AdoptOpenJDK):

https://blog.joda.org/2018/09/time-to-look-beyond-oracles-jdk.html

so I think reports of Java 8's demise are exaggerated.

But eventually there is need to move on. I am open to improvements to build system that allow dual-publishing, as long as they are not too intrusive (which I realize is vague and subjective statement). Certainly for 3.0 it would be nice to be able to add better definitions for module system to use; perhaps even for 2.10 (or whatever is the last 2.x minor version to be released).

On releasing versions: release process uses Maven release plugin, and this should remain the system. Having to release using post-Java8 JDK is fine (as well as probably the pre-requisite for any moduleized build?).

[GedMarc]

I've completed JDK 11 support in other pull requests using moditect.

[GedMarc]

Hi @cowtowncoder

Are we going to be targeting 2.10 or 3.x for this? For the pull requests...
For 3.x, can we please create a git repository that contains all the official Jackson JSON repo's as submodules?
Manually pulling each one creating branch, making fork, doing change, running build etc, is one hell of mission. xD

For JDK-8, it is best to adhere to the developers EOL, and not take part in custom releases that will only be targeted at certain vendors release. This doesn't make sense,

Please set Version 3 minimum JDK to JDK 11 with Strictly Named Modules. 2.10 can be JDK 8 quite safely, but the library will become obsolete a lot quicker if you keep on trying to support EOL JDK's in favour of libraries that are developed under the new conditions for Java.
Just a thought.

[cowtowncoder]

@GedMarc I don't do Git submodules, so that part would be no.

But as to 2.10 vs 3.x; I think we should go with 2.10 since progress towards 3.0 is still unpredictable and 2.x will probably be used for years now (based on experiences with 1.x).
Not sure what you mean wrt comments on Java 8 -- but regarding support for it (i.e. not requiring JDK beyond Java 8), I do want to keep support for quite a while now, as Java 8 development, deployments will certainly continue for couple of years at least.
So I will not be increasing baseline for Jackson 3 beyond Java 8 at this point, wrt usage.

Question of what to use for building is different however. Ideally I actually would want to keep Java 8 even for building, but if that is not feasible, yes, JDK 11 would do.

All I can say, Oracle has made life very difficult for Java developers and I hate having to play part in working around their bad decisions.

[GedMarc]

@cowtowncoder Ahhh that good 'ol age one :)

You know 6 months ago I would have agreed with you without even batting an eye. Today, 100% turn around. Then I got to thinking, this is actually as per usual. I remember when 1.4 got that overhaul into 1.5, Even when EE went 1.5, the same thing, and the same experience. hate it hate it hate it, why is it so hard, different different. coding an annotation processor shouldnt be like this.. bla bla bla..
But now, that I've used it, know it, deep dived through it, I definitely recommend taking the time, emptying the cup, and like everyone else, going "ahh, that's why there is no backwards compatibility for JPMS. That's bloody wonderful."

OK, I'll go the moditect route for the base library to keep it in sync with the JDK 8 dreams, but you are going to need to step in at some point to cover all the data types git repositories if that's ok? :)

I've updated the TeamCity builds and run it now for a good period, have it going in production smooth as silk.
These are the ones that I can confirm happiness with, and will do those pull requests for you hopefully soon. TM. The structure is very standardized among the module addons so little more than a browse over should do the trick.

https://jwebmp.com/teamcity/project.html?projectId=FasterXMLJacksonJpms&tab=projectOverview

For the JDK 11 compiler builds, My production builds are here https://mvnrepository.com/artifact/com.jwebmp.jre11.jackson

This is 2.9.8.

Thanks for making this brave move into JDK 11! Hope to not have to custom build these artifacts soon!

[cowtowncoder]

@GedMarc Yes, I think the way forward is to first focus on core components (annotations, streaming, databind), and hopefully figure out teething trouble, get that done for 2.10. Who knows, maybe I'll find my inner Modern Javaista -- I'm sure experience when doing the transition will be better than during or before.

And yes, I am fine doing work for things beyond basic set, once I get my head around work needed. I can usually imitate work with some sample conversions; this is mostly why Maven poms work -- anything advanced is contribution by someone else. I just copy-paste those things from source templates.

Apologies for being bit absent lately; I wanted to get 2.9.8 out with security fixes (done), as well as start working on backlog of 2.10 items that help with bit of future-proofing.

But I do want to get to play with forward-compatibility first, with Java 8 tools, and see how far that takes us. There are still issues to solve wrt packages to open, keep closed.
I think those are easier to tackle with core, and maybe selected few others... Afterburner will be tricky one, for example.

Anyway: perhaps we need to go back to hash out strategy, based on your work so far, my feedback, figure out a synthesis? I created this:

https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson3-Changes---Beyond-Java8

as poor-man's design doc. I think you should have access (github Wikis seem to be all-or-nothing-deals); if not, let me know.

[GedMarc]

@cowtowncoder Agreed on all accounts,

When playing with the data types modules and integration (I'm guessing 2.10 and 3.x will not have the deprecated module, I realised that a lot of people will actually have custom data type addons, In looking at this you are correct on the previous round of checks, that those packages should be exported openly for 2.x, and during the migration of 3.x the modules and packages should be restructured accordingly, I would like to take part in this phase for 3.x as well to ensure proper SPI handling and a few of those more "only-when-used" knowledge gatherings that i've come across

RestEasy 4.x as an example went ahead with a completely incorrect module separation for JPMS, but as its not documented in any way this knowledge is really gathered through use (https://issues.jboss.org/browse/RESTEASY-2110)

This weekend and most of next week I'm doing the JLink builds across these modules and distributions and learning all of those little knicks and knacks, I do believe my current config should "just work", but you never actually know until you build and run xD

When I pick this up after confirming JLink, there'll be a few of the pull requests for 2.10 which I hope will be pretty close to the final implementation :)

I have no doubt your inner Javaista will release free the moment you pick up/realise why E.E. was completely canned :) xD I loved that term, Modern Javaista, totally stolen!

[cowtowncoder]

@GedMarc Ok cool. We can plan for some incremental improvements for 2.10 too, as I hope it (and if there's 2.11, that too... we'll see) could bridge some of the gap towards clean(er) 3.0.

Also appreciate your help with other issues, sanity-checking reports & offering help. Not only does it help with my limited time, another pair of eyes gives more perspective. And it's maybe easier to have productive discussions, too, with more perspective.

As to 3.x, I definitely would like you to help & verify proper restructuring.

[cowtowncoder]

@GedMarc in related note: since this is bit obsolete wrt Moditect, was there another open PR for jackson-core?

[GedMarc]

@cowtowncoder I had a few PR's open but closed them all with relation to some new learnings and updates in the moditect base, specifically moditect/moditect#90 and moditect/moditect#78

There's also still the question of whether to place the module file in the base or in META-INF/versions/9 as @lukehutch has done with the ClassGraph project. On this there is a bug in the JDK which looks to be resolved in the upcoming 11.0.x.2 https://bugs.openjdk.java.net/browse/JDK-8207162 but the versions placement for those on the raw JDK 11 will be affected by this.
This does come with a few benefits such as not requiring to update jandex in the popular EE containers glassfish payara wildfly & swarm to remove a generated class scanning warning and keeps the module-info packaged for JPMS only as well.

Luckily all of these are really fast moving projects so there's no "show-stopper" yet.

But the reality is - as yet - I haven't been able to get a JLink working on any distribution smoothly, no matter where this file is placed, and it's related to a few things in the JPMS internals, and that everyone on this is still brand spanking new xD with little to no useful documentation anywhere ;)

[cowtowncoder]

As per earlier notes, support will be added in 2.10 using Moditect; closing this PR.