Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Declare Spring modules with JDK 9 module metadata [SPR-13501] #18079

Open
spring-projects-issues opened this issue Sep 24, 2015 · 15 comments
Open

Declare Spring modules with JDK 9 module metadata [SPR-13501] #18079

spring-projects-issues opened this issue Sep 24, 2015 · 15 comments
Assignees
Labels
type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 24, 2015

Juergen Hoeller opened SPR-13501 and commented

JDK 9's Jigsaw initiative aims to allow for module metadata (module-info.java) that can be added to framework and library jars while still keeping them compatible with JDK 8. Let's do this for Spring Framework 5.0's modules as far as feasible. However, we might not be able to express our optional dependency arrangement that way, in which case we might have to resort to an "automatic modules" approach for the more modest purposes of #18289.


Issue Links:

  • #18289 Stable module names for Spring Framework jars on JDK 9 module path ("depends on")
  • #17778 Upgrade core framework build to JDK 11 ("depends on")
  • #19148 Document Spring recommendations/restrictions for Java 9 module setups

1 votes, 12 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 15, 2016

Sam Brannen commented

Juergen Hoeller, is this issue a duplicate of #18289?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 22, 2016

Juergen Hoeller commented

Not necessarily: This one is about shipping explicit module-info.java files in our own jars, and is rather unlikely to happen at this point since we cannot express optional dependencies that way. However, for the purposes of #18289, we could also aim for what Jigsaw calls "automatic modules", i.e. putting our regular jars onto the module path and letting them participate in a module-based arrangement that way (with implicit access to all other modules).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 22, 2016

Sam Brannen commented

OK. I see the differences between the two issues now. Thanks for the clarification!

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 28, 2016

Juergen Hoeller commented

The Jigsaw page has just been updated with a proposal towards optional dependencies:
http://openjdk.java.net/projects/jigsaw/spec/issues/#CompileTimeDependences

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 17, 2017

Sam Brannen commented

while still keeping them compatible with JDK 9

Is that supposed to say "JDK 8"?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 5, 2018

Grigory Kislin commented

Hello!
Are module-info.java planned to add in Spring 5.1, as was announced in video [Spring Framework 5.0 on JDK 8 & 9|https://www.youtube.com/watch?v=0-sbPBf81KA]? In recent 5.1.RC2 version they are missed.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 12, 2018

Juergen Hoeller commented

This issue is marked as "General Backlog", indicating that we won't deal with it for 5.1 (otherwise it'd be marked for 5.1 GA still) and probably not in subsequent 5.x releases either (otherwise it'd be marked as "5.x Backlog").

Specifically, we can't ship module-info files quite yet since we'd need stable module names for all of our optional dependencies... and many of those don't declare stable module names at this point (that is, they don't even include an Automatic-Module-Name manifest entry in their jar). Also, we'd need to build the entire framework on JDK 9+ for the compiler to understand the module-info.java format which is not entirely trivial either, even if the framework itself is known to work fine with JDK 9/10/11 at runtime.

All in all, my prediction about module-info files for 5.1 turned out to be too ambitious. Our current focus is on general JDK 11 compatibility (#20937) on the classpath and as automatic modules on the module path, as well as GraalVM compatibility (#21529). The use of jlink requires manual addition of module-info.class files to the framework jars for the time being... which might stay that way for several years still until we ship a JDK 11 baselined Spring Framework 6.0 against a new generation of dependencies.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 30, 2018

yboompook commented

I tried to jlink my project with moditect (maven plugin to add module-info to dependencies that don't have one), java-11. I pass throw lot's of problem and it still doen't work, however I think my work could help you to make it work in spring 6.

poc on github

stackoverflow

@jabrena
Copy link

@jabrena jabrena commented Dec 19, 2020

Any progress with this issue?

@cesarbiods
Copy link

@cesarbiods cesarbiods commented Jan 5, 2021

Sounds like this will happen maybe 10-15 years from now and by then we'll be on JDK 50.

@xenoterracide
Copy link

@xenoterracide xenoterracide commented Jun 23, 2021

also checking in, is there anything that other people can help with on this? as I too would like to see more done than simply automatic module naming.

@lpandzic
Copy link

@lpandzic lpandzic commented Sep 24, 2021

It seems that new Java features might be more feature rich when using module system with one example being JEP 409: Sealed classes:

The classes specified by permits must be located near the superclass: either in the same module (if the superclass is in a named module) or in the same package (if the superclass is in the unnamed module).

My SO question on this topic.

While JEP 409 most likely won't be used much until JEP 406: Pattern Matching for switch comes out of preview, I believe this sets a clear precedent of where we are going.

@jhoeller jhoeller self-assigned this Sep 28, 2021
@jhoeller jhoeller removed this from the General Backlog milestone Sep 28, 2021
@jhoeller jhoeller added this to the 6.0 M1 milestone Sep 28, 2021
@dsyer
Copy link
Member

@dsyer dsyer commented Sep 28, 2021

For the sake of clarity, you can build a jlink package for a Spring Boot app. It works well with Java 11 and 17 (with 17 much leaner at runtime), but only includes JDK modules for reasons explained above - the other dependencies have to be added on the classpath. Notes here: https://github.com/dsyer/sample-docker-microservice.

@lpandzic
Copy link

@lpandzic lpandzic commented Sep 28, 2021

Just to reemphasize my previous comment: this is first example, that I know of, of a Java language feature being semi locked behind modularization.

Split packages are biggest obstacle to modularization and split packages are everywhere.

Regarding the Sealed Classes and Pattern matching I believe the pragmatic choice today is to either:

  1. put whole hierarchy inside one package
  2. put whole hierarchy in a separate Maven module and then Java modularize just that Maven module

I was surprised that things like Lombok work well with modularization with some configuration changes.

The clean way forward is to modularize the whole application but the ecosystem is simply not ready for this and unless a major player like Spring or Jakarta or someone else pushes "small" library maintainers to modularise their code I don't see modularization happening any time soon - it's simply too big of an undertaking for every developer to isolate/repackage every dependency that breaks modularization rules.

@jhoeller jhoeller removed this from the 6.0 M1 milestone Nov 24, 2021
@jhoeller jhoeller added this to the 6.0.x milestone Nov 24, 2021
@jhoeller jhoeller removed this from the 6.0.x milestone Feb 4, 2022
@jhoeller jhoeller added this to the 6.0.0-M5 milestone Feb 4, 2022
stliu added a commit to stliu/azure-sdk-for-java that referenced this issue Feb 23, 2022
…info.java in their libraries. We want to align this in our Spring implementations.

spring-projects/spring-framework#18079
saragluna added a commit to Azure/azure-sdk-for-java that referenced this issue Feb 23, 2022
…info (#27254)

* remove module-info, The Spring Framework 5.x does not support module-info.java in their libraries. We want to align this in our Spring implementations.

spring-projects/spring-framework#18079

* remove surefire plugin java modules proeprties from pom.xml

Co-authored-by: Xiaolu Dai <xiada@microsoft.com>
@Sineaggi
Copy link

@Sineaggi Sineaggi commented May 7, 2022

Now that Spring Framework 6 is on the horizon, have there been any thoughts towards moving to modules?

@jhoeller jhoeller removed this from the 6.0.0-M5 milestone May 19, 2022
@jhoeller jhoeller added this to the 6.0.0-M6 milestone May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement
Projects
None yet
Development

No branches or pull requests

9 participants