Combining -classpath and module-info?

[Stephan Herrmann]

Thanks a lot, Jon,

This is very helpful.

As you mention legacy mode as "no modules being compiled", this mode
is still tied to the -source, -target, and --release options, right?

IOW, the fact that the command line without module-info.java succeeds
is not owed to using a different compilation mode, but to compiling
everything in the same unnamed module, right?


Does JEP 261 have a process for correcting the text after it has been delivered?

Which space should I watch for updates?
- http://openjdk.java.net/jeps/261
- https://bugs.openjdk.java.net/browse/JDK-8061972
- any other?

regards,
Stephan

On 07.11.2017 23:03, Jonathan Gibbons wrote:
> 
> 
> On 11/07/2017 12:56 PM, Stephan Herrmann wrote:
>> On 07.11.2017 21:43, Alan Bateman wrote:
>>> On 07/11/2017 18:56, Stephan Herrmann wrote:
>>>> I recently noticed that compilers start to ignore -classpath as soon
>>>> as module-info (.java or .class) is found during the compile.
>>>> (Incidentally, javac and Eclipse compiler agree in this).
>>>>
>>>> Using a trivial test class this works:
>>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java
>>>>
>>>> This doesn't (cannot resolve any types from junit4.jar):
>>>> $ javac -classpath junit4.jar -d bin/ src/pkg/TestJUnit4.java src/module-info.java
>>> The module you are compiling doesn't read the unnamed module. You can't write "requires $CLASSPATH" for example.
>>>
>>> If you add `--add-reads <module>=ALL-UNNAMED` to the command line then it should compile.
>>>
>>> -Alan
>>
>> Thanks, Alan, that would work.
>>
>> But that is not what I meant when referring to JEP 261.
>>
>> In JEP 261 I see (under "Single-module mode"):
>> "It is possible to put arbitrary classes and JAR files on the class path in this mode,
>>  but that is not recommended since it amounts to treating those classes and JAR files as
>>  part of the module being compiled."
>>
>> Doesn't this say, my above command line treats junit4.jar as part of the current module,
>> *not* as an unnamed module?
>>
>> Is everything referenced via -classpath definitely treated as an unnamed module?
>> Independent of single-/multi-module modes?
>>
>> Stephan
> 
> Stephan,
> 
> I think you have identified some outdated text that needs to be fixed.
> 
> The text was correct at one point, when the distinction between "single module mode"
> and "multi-module mode" was a bigger deal.
> 
> These days, the primary distinction is between "classpath (legacy) mode" (no modules being compiled)
> and "module mode" (one or more modules being compiled.)
> 
> Here's how javac treats these modes:
> 
> In classpath (legacy) mode ...
> 
> * the sourcepath, classpath and output directory behave as previously, such as in JDK 8.
> 
> In module mode ...
> 
> * all classes on the classpath (-classpath) are treated as part of the unnamed module.
> 
> * if you are just compiling a single module, you may either put the source for that module
> on the source path (-sourcepath) or in a directory on the module source path (--module-source-path).
> 
> * if you are compiling multiple modules, they must be in separate directories on the
> module source path (--module-source-path).
> 
> * javac will implicitly look for previously compiled classes in the output directory (-d).
> (This is in contrast to the usage in classpath/legacy mode, where it has always been common practice
> to explicitly put the output directory on the classpath as well.)
> 
> -- Jon
> 
>