We Keep Coding

Java modules in IntelliJ and adding require java.ws.rs gives bizarre error

We have maven apps that until recently were on JDK8. We just upgraded them to JDK11 and are trying to take advantage of the JPMS from JDK9 by making our utility libraries into modules.
We originally had this kind of path:
utils/some-library1/src/main/java/com/company/team/utils/lib1/Util1.java
There, java is the "source root".
So a colleague placed the module-info.java file in the lib1 folder and declared it thus:
module utils.lib1 {
exports com.company.team.utils.lib1;
}
From the command line that builds and works, so he assumes everything is all module-y goodness.
But when I opened in Intellij, it had an ugly red line and the message said I should move it to source root. It then moved it to the "java" folder above. Fair enough.
That caused me to dig around trying to find out more about this JPMS that my colleague had implemented. After a lot of searching and experiments, I also determined that the "java" folder, as "source root", should be renamed to the name of the module ("utils.lib1"). So now I have these two files:
utils/some-library1/src/main/utils.lib1/module-info.java
utils/some-library1/src/main/utils.lib1/com/company/team/utils/lib1/Util1.java
And even Intellij is happy. Hooray! So I refactor all the other libraries. Suddenly I hit a major snag in let's call it lib2 with this line:
module utils.lib2 {
exports com.company.team.utils.lib2;
requires java.ws.rs;
}
Intellij flags the module with the red error squiggle again, this time saying:
Module 'utils.lib2' reads package 'javax.activation' from both 'jakarta.activation' and 'jakarta.activation'
I did some digging and found out the following:
java.ws.rs pulls in one of the following (it depends on which app):
javax.ws.rs-api-2.1.1.jar
jakarta.ws.rs-api-2.1.6.jar
Their module-info.java files contain this line:
requires transitive java.xml.bind;
Which pulls in one of:
jakarta.xml.bind-api-2.3.2.jar
jakarta.xml.bind-api-2.3.3.jar
jaxb-api-2.4.0-b180830.0359.jar
Which all have this line:
requires transitive jakarta.activation;
And that's where I give up. Our libraries are big hefty things that are hard to parse completely, so to simplify I created a maven app with just one class and all it does is import javax.ws.rs.core.Link.
And IntelliJ still gives that crazy error that I can't figure out and Google has been adamant in refusing to tell me.
Is it really broken or is Intellij just as confused as I?
I gave the long story both to show what we've done and to let you know that I'm very new to modules. So if it's a simple thing, please excuse me. I am just stumped though.
Additionally, are there any obvious tests one can perform at the command line to validate module configuration?
I've had inconsistent luck with jdeps, javac, and actually running as indicators of problems.
My suspicion is that things only work now because they're all in the unnamed module. But I need to get everything working if I'm going to convince anyone to change it.
EDIT
This question was reported as already answered, but that is incorrect. The suggested link deals with two different packages (A & B) importing package X. But in my case, the error is that the same package (A & A) imports package X. And this is done a few transitives down, so I have no control over the imports and can't see how to do an exclusion. Also, this problem can be repeated with just single requires statement in module-info.java!
Plus, there is a second question here that is also important that has not been addressed: how to validate the module configuration from command line (without involving the IDE at all).

I also determined that the "java" folder, as "source root", should be renamed to the name of the module
No, it should not. The java source root should be left as is but you must create a package name corresponding to your module name, so it should be /src/main/java/ - source root and then utils/lib1 directory - whidh would be the package.

I came across exact same warning in Intellij and it was genuine. In my case the collision was coming from three separate dependencies using same module name (i.e. 'jakarta.activation'):
'jakarta.activation:jakarta.activation-api:1.2.2'
'javax.activation:javax.activation-api:1.2.0'
'com.sun.activation:jakarta.activation:1.2.2'
It got it resolved for my project by applying explicit exclusions on dependencies which were pulling the last two.

Practical use for requires static from java module system [duplicate]

This question already has answers here:
What's the difference between requires and requires static in module declaration
(2 answers)
Does the Java 9 Module system support optional dependencies?
(1 answer)
Closed 3 years ago.
I started to learn jigsaw java-9 feature and read some articles/video.
I can't understand concept of optional dependencies(requires static)
quote from article:
When a module needs to be compiled against types from another module
but does not want to depend on it at run time, it can use a requires
static clause. If foo requires static bar, the module system behaves
different at compile and run time:
At compile time, bar must be present or there will be an error. During
compilation bar is readable by foo.
At run time, bar might be absent
and that will cause neither error nor warning. If it is present, it is
readable by foo.
So I want to know couple of things:
What the reason to make module dependable on another module during compile time but not in runtime? any examples? instruments like lombok?
Any analogs of optional dependencies in java prior java-9 ?
P.S.
I found one more explanation:
quote from article:
Sometimes we write code that references another module, but that users
of our library will never want to use.
For instance, we might write a utility function that pretty-prints our
internal state when another logging module is present. But, not every
consumer of our library will want this functionality, and they don’t
want to include an extra logging library.
In these cases, we want to use an optional dependency. By using the
requires static directive, we create a compile-time-only dependency:
module my.module {
requires static module.name;
}
But it is absolutely unclear for me. Could anyone explain it in a simple way?

There are a decent number of libraries out there where it only makes sense to have them at compile time. Mostly this deals with annotations that only exist to help during development (e.g. prevent bugs, reduce boilerplate). Some examples include:
java-annotations by JetBrains
spotbugs-annotations by SpotBugs (successor of FindBugs)
Project Lombok (as you mentioned)
jcip-annotations
These annotations tend to have a RetentionPolicy of SOURCE or CLASS, which means they aren't useful (or even available) at runtime. Why ship these dependencies with the rest of your application when you deploy? Without requires static you would be forced to include them when you deploy, otherwise your application would fail to start due to missing dependencies.
You would declare these dependencies as optional pre-Java 9 as well. Many Java projects of any significance use a build tool such as Maven or Gradle. In addition to those tools automatically building and testing your project, a large part of what they do is dependency management. I'm not familiar enough with Maven, but when using Gradle one would use:
dependencies {
compileOnly 'group.id:artifact-id:version'
}
To declare dependencies that are not needed at runtime.

If Dependent Module should be available at compile time but optional at rumtime, then such type of Dependency is called Optional Dependency. We can Specify optional dependency by using static keyword.
Note The static keyword is used to say that "This dependency check is mandatory at compile time and optional at runtime."
Eg.1
module moduleB {
requires moduleA;
}
moudleA should be available at the time of compilation & rumtime. it is not Optional Dependency.
Eg2.
module moduleB {
requires static moduleA;
}
At the time of compilation moduleA should be available, but at runtime it is optional ie, at runtime even moduleA is not avaiable JVM will execute code.

How split packages are avoided in Java 9

I am new to Java 9 and was going though the modular video lectures by Java on YouTube.
They mentioned 3 benefits of modularization-
1. No missing dependencies
2. No cyclic dependnpcies
3. No split packages.
As far as I understand about split packages is that let's say an application is dependant on multiple dependncies and let's say package abc.pqr.xyz is present in more that 1 jar.
Then there is a chance that some of the classes in that package will be used from jar1 while other classes from jar2.
This might lead to some problems at runtime which will be hard to debug.
Video says modularization solves this issue.
But how that's what I am trying to understand?
Let's say there is test.module1 which has below module info -
module test.module1{
exports abc.pqr.xyz;
}
Another module2 with below module info-
module test.module2{
exports abc.pqr.xyz;
}
Now let's say in my application I added dependencies of both of these modules-
module test.myapp{
requires test.module1;
requires test.module2;
}
Now again I have 2 modular dependencies where there is a chance that some of the classes will be present in both of these modules.
So at runtime how it will be resolved from which module to pick up the class definitions?
How Java 9 will avoid split packages problem?

With the scenario described in the question, you'll start facing an error reading :
Module test.myapp reads package from both test.module1 and test.module2
Readability of the Modules from The State of the Module System elaborates over the use of Modules as follows and shall interest your use-case(emphasis mine):
The readability relationships defined in a module graph are the basis
of reliable configuration: The module system ensures
that every dependence is fulfilled by precisely one other module
that the module graph is acyclic
that every module reads at most one module defining a given package
and that modules defining identically-named packages do not interfere with each other.
the benefit of implying the same in the module system is detailed as well
Reliable configuration is not just more reliable; it can also be
faster. When code in a module refers to a type in a package then that
package is guaranteed to be defined either in that module or in
precisely one of the modules read by that module.
When looking for the
definition of a specific type there is, therefore, no need to search
for it in multiple modules or, worse, along the entire class path.
That said, the current solution to your implementation is
if the modules test.module1 and test.module2 are explicit modules, you can choose to implement the package abc.pqr.xyz in either one of them
OR you pull it out from both into a separate module test.mergeModule of your own which can thereafter be used as an independent module across its clients.
if these(or any one of them) are automatic modules, you can make use of the bridge extended to the classpath and let such jar remain on the classpath and be treated as the unnamed module, which shall by default export all of its packages. At the same time, any automatic module while reading every other named module is also made to read the unnamed module.
Quoting the document again and to illustrate with an example, so that you can correlate to your question :
If code in the explicit module com.foo.app refers to a public type in
com.foo.bar, e.g., and the signature of that type refers to a type in
one of the JAR files still on the class path, then the code in
com.foo.app will not be able to access that type since com.foo.app
cannot depend upon the unnamed module.
This can be remedied by treating com.foo.app as an automatic module temporarily, so that its
code can access types from the class path, until such time as the
relevant JAR file on the class path can be treated as an automatic
module or converted into an explicit module.

The Java module system resolves the split package problem by rejecting this sort of scenario at JVM startup time. When the JVM starts it will immediately begin resolving the module graph, and when it encounters two modules in test.myapp's module path, the JVM will throw an error indicating test.module1 and test.module2 are attempting to export the same package.

"Hide" a maven artifact from the eclipse autocomplete

For reasons I don't even want to begin to get into.. I have a maven hierarchy that looks like the one below. In a nutshell, everything requires commonslang3, except one ancient artifact that requires commonslang2.
We have no issues with compile or runtime, the dependencies work as expected. The challenge we are having is at development time.
We'd like to ensure everyone on the team uses the commonslang3 APIs, but occasionally (because of the ancient artifact and Eclipse auto suggest), someone accidentally uses the commonslang2 APIs.
Normally, we would just force the desired version in our POM, but commonslang is a special snowflake. The package signature changed between comonslang2 and commonslang3, which means we would have compile failures if we excluded the older library. E.g.,
org.apache.commons.lang3.StringUtils
org.apache.commons.lang.StringUtils
My question is this, how can I configure maven/Eclipse, to use commonlang2 as needed during compile... but not populate it in the Eclipse class autosuggest list? My desired end state is that someone types 'stringuti' + ctrl + space, and the only option they see is commonslang3. I am aware that each developer can remove individual classes via (Window->Preferences->Java->Appearance->Type Filters) but that is not a viable solution for two reasons: 1) It's a large team with frequently changing resources... 2) I need an entire artifact removed, as in hundreds of classes.
Example Tree:
MyWar
-- MyModuleJar1
-- ...
-- MyModuleJar2
-- LibA
-- commonslang
-- ...
-- LibB
-- commonslang3
-- ...
-- LibC
-- commonslang3
-- ...
-- ...

In Eclipse:
Window->Preferences->Java->Appearance->Type Filters
Add org.apache.commons.lang.*
Because you want to affect auto-complete which is a function of the IDE, you are forced to change the setting in the IDE. You can export the preferences and share them of the rest of the team.

There is not much you can do about it in Eclipse other than type filters #JustinKSU mentioned.
But with Maven you can use Takari to access rules to prevent accidental inclusion of transitive dependencies. Of course this comes with a plethora of caveats with one ironically being that the Eclipse JDT compiler has to be used instead of plain javac.

How to use separate class loaders and run in same JVM? (OSGI)

I've read that OSGI uses separate classloaders per module which allows modules to use different versions of their dependencies.. while at the same time running all modules in the same JVM.
How does this work? If module A uses version #1 of a dependency and module B uses version #2, won't you run into trouble if module A passes an instance of the dependency class to module B as a method parameter?
I would think module B would choke if it was expecting a different interface to the dependency class.

You're right that inconsistent dependencies can cause problems. OSGi avoids this by calculating the transitive closure of these dependencies and ensuring that there are none at resolution time.
This allows you to expose a public dependency whilst having internal/hidden private dependencies and, as a result, hide your implementation dependencies to avoid this. The good thing is all thus is checked at Bundle resolution time rather than obscure runtime errors.
Specifically in your example, if A and B uses an incompatible interface, and A depends on B, then A will fail to resolve with a dependency error. So it won't even be able to start to pass it an incompatible type.