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

Reply via email to