|Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9|
There is, it’s called JPMS and once you have a module declaration (both explitic or automatic) in the module-path this works, the behavior is specified by the Java SE platform and I see no reason why we would have to do anything in Jakata EE on that.
As long as those specs that did a great Job in properly declaring module-info are not forced to destroy that (including Services and lots of other stuff) and rip it out only to put it back in again, I guess I could live with removing the automatic-module-name from the POM because that is a lot less work and could even be commented out for now.
However, there shall be no renaming later, so if it’s called "jakarta.activation" or "jakarta.json" in a proper module-info, then it must not change.
Especially those two are fairly independent and used not just by Jakarta EE components or different specs, they are used by other types of applications including Maven plugins etc. or by the Spring stack and there automatic-module-name is also what every Spring JAR I saw lately does, therefore we’d lose an advantage compared to Spring if we removed the automatic-module-name now, but it would help clean the mess that so far only exists in those automatic module names.
How are we intending developers to use the module names that get specified by the spec JARs? I have not seen any indication that there is a standards based way to build a Jakarta EE application out of JPMS modules. Furthermore there is no specified behavior for how a Jakarta EE platform implementation would load such an application as modules at runtime. Any such support will have to be implementation specific and that implementation likely will need to have a coherent set of modules it provides to implement the platform out of modules. Any such application will likely need to target that specific implementation until there is a standard way of doing this. If Jakarta ever decides modules have to be supported at runtime I am sure it will likely look different from any decisions we try to make today for module names.
For this reason I agree with Scott that it probably does more good to remove the Automatic-Module-Name headers from all specification JARs.
Back to the top