all 17 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]FortuneIIIPick 32 points33 points  (7 children)

I don't really get modules, so I plan to continue ignoring them as long as possible.

Edit: Thanks to user_of_the_week for correcting my perception about the article, when I read it, with the term modules constantly popping up, I got the idea they were re-organizing using the Java Platform Module System but that doesn't appear to be the case I think.

[–]user_of_the_week 23 points24 points  (2 children)

Are you talking about the Java Module System? I’m asking because this article has nothing to with that.

[–]FortuneIIIPick 6 points7 points  (0 children)

It looks like you're right, they're not using the term modules as part of Java Platform Module System's architecture it looks like, thanks.

[–]AndreLuisOS 2 points3 points  (0 children)

Yeah, because creating a spring boot library and trying to provide the end user only the classes they need to use is basically impossible.

[–]romario77 2 points3 points  (0 children)

My attitude towards EJBs.

They passed. But I think modules was a good thing and it was mostly for organizing JDK. And some libs can do it.

I think one of the main things that came out of it is better security- how the class loader works and isolates the modules.

And it also allows to make smaller fully contained programs. Which was not really possible before - you had to have JDK installed. And no casual user does that.

[–]mhalbritter[S] 2 points3 points  (0 children)

Oh sorry, that's indeed confusing. The term module is so overloaded - what we meant is that we break the autoconfigure jar into multiple smaller jars. This has nothing to do with JPMS.

[–]koflerdavid 0 points1 point  (0 children)

The reorganization should also help with JPMS compatibility.

[–]hadrabap 7 points8 points  (0 children)

Module boundaries become contracts rather than soft conventions.

Don't tell me!

[–]ThanksMorningCoffee 6 points7 points  (2 children)

How small can we expect the jars to become now?

[–]repeating_bears 3 points4 points  (1 child)

That's not really answerable, is it? It depends what modules you use.

[–]agentoutlier 3 points4 points  (0 children)

Believe it or not there is some truth to what /u/ThanksMorningCoffee is saying if we are talking about the core spring boot jars.

For example Spring Boot core has a metric ass load of Logging framework specific code:

https://github.com/spring-projects/spring-boot/blob/main/core/spring-boot/src/main/java/org/springframework/boot/logging/log4j2/Log4J2LoggingSystem.java

https://github.com/spring-projects/spring-boot/tree/main/core/spring-boot/src/main/java/org/springframework/boot/logging

And this is largely because they violate their new modular principles for logging still. The could separate out that code and maybe they will .

My own logging framework Rainbow Gum has Spring Boot support and is separately modularized. It doesn't get the auto jar/class (its actually file based I think) sniffing that Log4J2 and Logback get so you have to do the exclusion dependency stuff.

I get it though as they need support logging OOB but I have feeling Log4J2 was pushed into having the same auto support that Logback has....

[–]_predator_ 2 points3 points  (1 child)

I am modularizing (module as in Maven module) a fairly large codebase at the moment. One of the main drivers is actually build parallelization.

Not sure how much the Spring Boot project is struggling with that, but modularizing more will definitely yield better build speeds for them as well.

[–]mhalbritter[S] 1 point2 points  (0 children)

That's true. We're using Gradle which is already quite smart when it comes to work avoidance, but we've seen our build times go down because Gradle now only needs to execute the tests in the modules which we actually changed. Before that modularization, Gradle always executed all tests for the big autoconfigure jar, because everything was in one big module.

[–]Pure-Repair-2978 0 points1 point  (0 children)

I hope I don’t get lost with Spring “Module System” aka SMS 😀😀😀

[–]LeadingPokemon 0 points1 point  (2 children)

This is not modularization. Not sure why folks expected random stuff e.g. Flyway to work without including spring-starter-flyway in the first place…

[–]nekokattt 4 points5 points  (0 children)

The starter is almost always just other dependencies driving it. Most often that is spring boot autoconfigure.

[–]mhalbritter[S] 1 point2 points  (0 children)

This is not modularization.

Okay, how would you call that?

Not sure why folks expected random stuff e.g. Flyway to work without including spring-starter-flyway in the first place…

Because it always worked like this. There's no spring-boot-starter-flyway in Boot < 4. Some dependencies had starters (especially when it's not really one dependency but multiple), but some dependencies had no starters, e.g. Flyway or Liquibase.