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
-----------
