[External] : Re: Inconsistency with service loading by layer or by class loader

[Andrew Dinn]

On 14/12/2024 00:20, Ron Pressler wrote:
>> The problem is the run time behavioral differences.
> 
> That would indeed be a problem if you want *every* JAR to work both
> on the module path and on the classpath but, as far as I know,
> making that easy or even possible *for every JAR* is not and has
> never been the goal of the platform. I'm not saying it shouldn’t be
> the goal, nor am I trying to dismiss the difficulty of achieving
> that currently (which is expected given it’s not a goal of the
> platform as it currently is). I’m merely trying to understand *why*
> that’s needed.

David pointed out earlier that 'working on the module path' is almost 
always not a requirement for a Java library developer -- n.b. when I say 
'almost always' you need to think of some sort of Lebesgue measure zero 
'almost everywhere' meaning rather than, say, 90/10 or 99/1.

That's because most libraries are going to need to rely on at least one 
other library, maybe several,-- probably written by a third party,-- 
those libraries likely depend on other libraries, and so on. Making the 
new library 'work  on the module path' requires making the full closure 
'work' i.e. for almost all (non-leaf) library developers requires 
large-scale, co-ordinated changes by multiple developers who usually do 
not even know of each others existence. As a further complication, many 
libraries in the chain, especially leaf libraries, will be in 
maintenance mode and no one will be interested in performing even the 
most minor refactoring.

That is indeed why most people have not, do not and will not implement 
modular libraries. Effectively modules are only useful when it comes to 
adding a completely new suite of libraries to the Java eco-system, one 
that has been built from the bottom up and can afford to ignore (or 
possibly replicate) all the existing investment in development, 
maintenance and, crucially, developer familiarity and experience.

n.b. given the scale of the existing classpath-based eco-system, the 
largesse required to render meaningful that parenthetic term 'or 
possibly replicate' suggests I probably ought to have said 'or, 
impossibly, replicate'.

So, why on earth is David bothering to look at making existing libraries 
work both on the module path and on the classpath. Well, I cannot speak 
for David but, having talked to him and other Red Hat Java library 
developers I can make what I believe to be an informed speculation. No 
doubt he can and will (should) correct me if I am misreading him.

I suspect David believes that the platform is moving towards privileging 
modular libraries and, in doing so, in equal measure de-privileging 
non-modular libraries, making it hard or, even, impossible for them to 
continue to function in upcoming JDK releases. He appears, as a 
consequence, to be investigating the use of module layers to automate 
deploying classpath jars so they can operate as modules with their 
attendant privileges and, in doing so, employ the other libraries they 
depend on, also operating as modules i.e. he is trying to work out how 
to resolve the problem that has led to modules being ignored 'almost 
always'.

So, I don't believe this is being done as a vote of confidence in the 
value of the module system. Far from it, this appears to me to be a 
rearguard action to allow the critical mass of the Java library 
eco-system to continue to operate, despite current and future 
constraints imposed by module system.

One further point: when you asked whether this is to do with 'JBoss' 
(meaning, I suspect, the Red Hat application server) I am sure the 
answer is no. I don't believe this is motivated by a desire simply to 
keep that one Red Hat product, nor even the many other Red Hat libraries 
and middleware frameworks operational. If nothing else, Red Hat's large 
suite of Java libraries depend on thousands of 3rd party libraries, so a 
lot of non-Red Hat code is implicated on those grounds at least. 
However, I think David's concern is wider, comprising the whole 
classpath-based Java eco-system, which n.b. one might also characterise 
as the predominant code base that gives value, carried forward, to Java 
as a development and deployment platform.

regards,


Andrew Dinn
-----------