Le 2024-01-02 à 20 h 51, Romain Manni-Bucau a écrit :
RMB: so you mean you don't intend to link the classpath to the type?
Not directly. The code dispatching JAR files between classpath,
module-path, etc., bases fully its decision on the following:
* DependencyProperties
* Sometime whether the dependency is modularized (whether to do this
check or not depends on the properties)
* In the specific case of --patch-module, dependencies previously
added on --module-path.
In the older proposal, DependencyProperties were determined by the Type.
So this is where classpath was indirectly linked to type. However, it
seems to have changed in a commit on December 14th, and I'm not sure
what is the new way. But I will adapt.
assuming all the toggles you spoke about (let's focus on jpms for now)
are shared by plugins, this is not the case, javadoc, surefire and
compiler don't share them most of the time - it is the same for
exports/opens in another JVM area.
My proposal is to gradually move away from that situation to a situation
where the paths are managed in shared code, at least for standard tools.
It does not mean that plugins cannot customize.
RMB: Probably the majority, not sure it is vast or just most of cases
Let's do a prototype, then create test cases showing the limitations.
What are the proven limitations will give us a better idea about whether
the prototype covers a majority of cases or not.
And this is a key point, this classpath definition is needed for any
project, not only JPMS, and this solution is specific to JPMS since it
ignores most of plugins outside java ecosystem,
The proposal also covers taglet, doclet, annotation processor, agent,
etc., and is extensible so that plugins can define their own path types.
The proposal needs to be made more extensible, but I don't think it will
be a problem if the principle is accepted.
In some way, the proposal has a little bit of similarity with the
"dependency sets" you proposed. The DependencyProperties interface
contains properties such as IS_CLASSPATH_CONSTITUENT,
IS_MODULEPATH_CONSTITUENT, etc., which are boolean values. They could be
interpreted as "this dependency is a member of the classpath set", "this
dependency is a member of the module-path set", etc. I was thinking to
replace those properties by a single property telling directly in which
set(s) this dependency belong, but I thought that it does not need to be
debated now because it is a very minor change.
annotation processor is core to java since 20 years, never been core
to any build tool even if widely used so for me it is 100% about the
usage and adoption/consumer need.
Annotation processor does not replace classpath. By contrast,
module-path replaces fully the classpath if all dependencies are
modularized. I see class-path as legacy, which would be deprecated if
enough dependencies in the Java ecosystem were modularized.
the interface is almost the same for all, ack...does not mean they
will consume the same artifacts for all these options
Yes, this is why scope exists. An artifact may be compile-time only, or
runtime only, etc. But if an artifact is included, it should (at least
by default) always be placed consistently on the class-path or
module-path. Other kinds of path (doclet, etc.) work in a similar way.
will you create a type=javadoc-module-path, type=javac-module-path etc
No, it is not my plan. I believe that making inconsistent "classpath
versus module-path" choices for different tools is asking for trouble.
To be convinced otherwise, I would need to see a small "hello world"
application compiled and executed on the command line with inconsistent
options, with an explanation demonstrating that the inconsistency is
required for making the application works.
Martin
