• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is my understanding correct - you cannot use both classpath and modulepath together?

 
Ranch Foreman
Posts: 466
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sybex 829 Chapter 12

A key point to remember is that code on the classpath can access the module path. By contrast, code on the module path is unable to read from the classpath.



I was trying to understand this and am wondering whether it is correct to conclude that you cannot use both classpath and modulepath together?

Is that why code on the module path is unable to read from the classpath?
Because both the classpath and modulepath are just a list of directories that one specifies on the command line for java and also javac.
 
Saloon Keeper
Posts: 15450
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

A key point to remember is that code on the classpath can access the module path.


This line is pretty clear. Yes, you can use them together.
 
Bartender
Posts: 3901
43
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anil Philip wrote:Sybex 829 Chapter 12

A key point to remember is that code on the classpath can access the module path. By contrast, code on the module path is unable to read from the classpath.



I was trying to understand this and am wondering whether it is correct to conclude that you cannot use both classpath and modulepath together?

Is that why code on the module path is unable to read from the classpath?
Because both the classpath and modulepath are just a list of directories that one specifies on the command line for java and also javac.



You need to think not by directory categories, but by module categories ;)

1) When you have module options in the command line, the program runs as a modular
2) All content of the classpath goes to the unnamed module
3) A named module cannot read the unnamed module, because the unnamed one has no name, so cannot be listed in the module descriptor as required ;)
4) Unnamed module (containing classpath classes) implicitly exports all packages and implicitly requires all modules from the module path
For this reason, classes from classpath can see classes from modules (as long as modular packages are exported)

Hope this helps ;)
 
Anil Philip
Ranch Foreman
Posts: 466
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mikalai Zaikin wrote:
You need to think not by directory categories, but by module categories ;)

1) When you have module options in the command line, the program runs as a modular
2) All content of the classpath goes to the unnamed module
3) A named module cannot read the unnamed module, because the unnamed one has no name, so cannot be listed in the module descriptor as required ;)
4) Unnamed module (containing classpath classes) implicitly exports all packages and implicitly requires all modules from the module path
For this reason, classes from classpath can see classes from modules (as long as modular packages are exported)

Hope this helps ;)



Regarding the sentence

code on the module path is unable to read from the classpath.



If, as Stefan said, you can have both -p and -cp together, then can code in the module moduleName access the non-modularized jars in jarFolderName ?
 
Enthuware Software Support
Posts: 4798
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anil Philip wrote:

If, as Stefan said, you can have both -p and -cp together, then can code in the module moduleName access the non-modularized jars in jarFolderName ?


Yes, but only if it is an automatic module.
 
Paul Anilprem
Enthuware Software Support
Posts: 4798
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Classes from a regular named module cannot access/read classes from classpath.
(fixed typo)
 
Anil Philip
Ranch Foreman
Posts: 466
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Anilprem wrote:Classes from a regular named module cannot access/read classes from classpath.
(fixed typo)



But why not? if you left out the -p then wouldn't it regress to the old-style prehistoric invocation using classpath?



becomes


which is not much different from

 
Stephan van Hulst
Saloon Keeper
Posts: 15450
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have you actually tried it?
 
Anil Philip
Ranch Foreman
Posts: 466
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Have you actually tried it?


I confess, I haven't.
Creating modules seems a lot more complicated than just creating a class and running it.
 
Marshal
Posts: 28141
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anil Philip wrote:Creating modules seems a lot more complicated than just creating a class and running it.



This is true. That's why my recent project to catch up on Java one release at a time stumbled at Java 9. I have to admit I decided to skip over modules and carry on.

But stick with it. I expect that getting up to speed with all of the picky features of the classpath was a chore at first, and the module path is going to be similar.
 
Paul Anilprem
Enthuware Software Support
Posts: 4798
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anil Philip wrote:

But why not? if you left out the -p then wouldn't it regress to the old-style prehistoric invocation using classpath?


Already answered by Mikalai above:


1) When you have module options in the command line, the program runs as a modular


 
Anil Philip
Ranch Foreman
Posts: 466
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Anilprem wrote:

Anil Philip wrote:

But why not? if you left out the -p then wouldn't it regress to the old-style prehistoric invocation using classpath?


Already answered by Mikalai above:


1) When you have module options in the command line, the program runs as a modular




Ok, I did not realize that. Thanks!
 
Anil Philip
Ranch Foreman
Posts: 466
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:

Anil Philip wrote:Creating modules seems a lot more complicated than just creating a class and running it.



This is true. That's why my recent project to catch up on Java one release at a time stumbled at Java 9. I have to admit I decided to skip over modules and carry on.



I heard Simon Roberts say in one of his virtual classes a long time ago, that Java Modules are not used much in the real world.
I could be mistaken but I think modules are useful only if you are distributing a library.
Within an organization, why would you need it? I am wondering if it just adds to more convolution.
 
Stephan van Hulst
Saloon Keeper
Posts: 15450
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why would modules be useful to the public at large, but not to a company internally? Aren't companies interested in modular applications?

It's true that not as many libraries are created as a module as there might have been. This has two important reasons:

  • The designers did make JPMS a bit harder to use than it should have been.
  • Programmers are lazy.

  • Once you get the hang of JPMS, there really isn't much reason NOT to make your libraries into modules; especially when you use a build tool like Maven: you only need to take two minutes to write a module descriptor to give your module a name and list its dependencies on other modules. Of course there are some cases that require more effort, but you can just update the descriptor as you update the application.

    The only good reason I've encountered to forego making a library into a named module is when it uses a lot of non-modular dependencies consisting of split packages.
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4798
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:you only need to take two minutes to write a module descriptor to give your module a name and list its dependencies on other modules.


    That's a red herring, imho. Time required to write/update a module description ignores the times required to "reload" the module knowledge base into your brain. Unlike regular java code that I write every day, module-info.java is used rarely and that makes me forget its operating parts.

    It is like if I have to create an executable jar, I still have to look up whether it is Main-Class or Mainclass or something else that I need to add to meta-inf. Is it meta-inf.mf or something else?

    It is the looking up part and not the writing part that dissuades programmers from using modules. Most projects are used internally anyway and rarely do teams care about modules, tbh. There is no time for them.

    Having said that, I think the module functionality is pretty neat for what it is meant to achieve.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15450
    363
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I agree that would be the case if you don't regularly make modules, but it's also a bit of circular logic: "I don't create modules because I'm not familiar with them. I'm not familiar with modules because I don't create them".

    If you habitually create well encapsulated modules the same way you habitually create well encapsulated classes, there shouldn't be an issue.
     
    Author
    Posts: 278
    11
    Scala IntelliJ IDE Netbeans IDE Python Java Ubuntu Linux
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Anil,

    If you have the time, take a look at my pre-recorded modules class. The second half of it focuses on migrating non-modular projects to the module system, which can rarely be done in a single step if they're large. In that situation a mix of classpath and module path is a practical necessity.

    As to my belief that this isn't used much, I would add some notes/context:
    1) it's based on my personal experience teaching in a fair number of different, large, companies. However, it by no means claims some kind of omniscience! YMMV.
    2) It's also most definitely *not* a value judgement--I believe the system has much to offer; in terms of security, in terms of improving a project's overall architecture and dependency management, and, mostly for those that provide stand alone applications to clients, deployment.
    3) To point 2) above, it's a sad reality that a lot of commercial projects are more interested in adding features than any of those points. I note that we've had many security breaches in Java based systems that would have been prevented by the use of the SecurityManager. But using the SecurityManager was "hard" and didn't *add* any functionality. It got so little use that it was deprecated and removed. I spent years trying to explain to folks how and why they could/should use that. To no avail, clearly. Go figure
    4) It's certainly true (as someone noted above) that there's a circular logic here--"I don't use it so I don't know it, and I don't know it so I don't use it" (credit to whomever said that first above!)
    5) It's also potentially tricky to migrate a project to modules. One circular dependency and the whole effort has a bad habit of stalling out and going unfinished. That (not entirely unreasonably) scares folks, and makes the project seem high risk for ... oh here we go again .. no additional features.

    But, do I think that a *new* project should be created using it? Heck yes. Do *I* think that migrating real projects is worth it, well, yes again. That doesn't mean it happens every time though.

    Check out my pre-recorded JPMS class with your O'Reilly subscription (or 1 week free trial here:

    https://learning.oreilly.com/course/up-and-running/9780137475216/

    $0.02,
    Simon
     
    Anil Philip
    Ranch Foreman
    Posts: 466
    1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Simon Roberts wrote:
    But, do I think that a *new* project should be created using it? Heck yes. Do *I* think that migrating real projects is worth it, well, yes again. That doesn't mean it happens every time though.



    Simon, It's great to see you here!
    I think that JPMS is not used much because in my limited skill and experience,
    1) Java is just one of many components nowadays that a developer must learn to keep his job.
    There are too many things in a laundry list of tools, frameworks, languages and components to learn.
    JPMS adds to the complexity.
    By forcing a new way to compile and run for example, new options for java and javac require maven files to be 'different' which means every developer must know exactly how to use this new jargon.
    2) Unless you are creating a library or framework for others to use, why bother? Most Java code in companies are Microservices using Spring Boot and the things that go with it. It adds enough configuration and complexity by itself.
    The JVM forms a natural boundary. A microservice is a de-facto module by itself.
     
    Simon Roberts
    Author
    Posts: 278
    11
    Scala IntelliJ IDE Netbeans IDE Python Java Ubuntu Linux
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I think there is some merit in your observations Anil, but it's perhaps worth pointing out that much of the load of creating a modular program should fall on the architects. The average programmer should not be too heavily involved. If they are, it suggests to me that the boundaries have not been properly laid, and those programmers are crossing said boundaries!

    And even a microservice would benefit from additional security, no? 😁

    But it certainly true that inertia comes in many forms, and unless there is sufficient perceived benefit, nobody's going to make the effort.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15450
    363
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Anil Philip wrote:By forcing a new way to compile and run for example, new options for java and javac require maven files to be 'different' which means every developer must know exactly how to use this new jargon.


    Please provide an example of how JPMS affects how you write your Maven POMs.

    Unless you are creating a library or framework for others to use, why bother? Most Java code in companies are Microservices using Spring Boot and the things that go with it.


    Companies also write reusable libraries for internal use. Companies also benefit from the encapsulation and modularity that JPMS modules bring. Companies can also use JPMS to release smaller runtimes for a specific application.

    Finally, not nearly every company that uses Java to write applications also uses Spring. I've been using Java professionally for many years now, and I've never written a single line of code for a Spring application unless it was for a hobby project.

    The JVM forms a natural boundary. A microservice is a de-facto module by itself.


    This makes absolutely no sense. First, microservices are not atomic in terms of build artefacts. Pretty much every microservice consists of multiple libraries. Those libraries can be reused in different microservices.

    Secondly, there is not a one-to-one mapping between microservices and virtual machine instances. Multiple microservices can run inside of the same JVM instance.

    Finally, microservices are hardly the be-all and end-all of software architecture. Monolithic applications still have their place (especially in younger applications) and it's only after careful deliberation that you redesign an application as a collection of microservices.
     
    Paul Clapham
    Marshal
    Posts: 28141
    95
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Clapham wrote:I have to admit I decided to skip over modules and carry on.


    Just to clarify: this was only partially because there seemed to be a lot to learn. There have been a lot of changes between Java 8 and Java 21, and I haven't looked at all of them by any means. For example all those changes which are improving Vector handling over many releases are of no relevance to me so I have just ignored them. Modules are in that category too, as far as I can see.
     
    Simon Roberts
    Author
    Posts: 278
    11
    Scala IntelliJ IDE Netbeans IDE Python Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:

    Anil Philip wrote:

    If, as Stefan said, you can have both -p and -cp together, then can code in the module moduleName access the non-modularized jars in jarFolderName ?


    Yes, but only if it is an automatic module.



    Except that the example here asks about "modularized jars in jarFolderName" -- and jarFolderName is on the classpath, *not* the module path, so they're not going to be automatic modules, and the above will not work.
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4798
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Simon Roberts wrote:

    Paul Anilprem wrote:

    Anil Philip wrote:

    If, as Stefan said, you can have both -p and -cp together, then can code in the module moduleName access the non-modularized jars in jarFolderName ?


    Yes, but only if it is an automatic module.



    Except that the example here asks about "modularized jars in jarFolderName" -- and jarFolderName is on the classpath, *not* the module path, so they're not going to be automatic modules, and the above will not work.



    You are right. I think I replied from my mobile and didn't check the actual command and posted the response based on just the world "jarFolderName". A jarFolderName has no business being on the classpath. You can only put a jarFolderName on the module path and the jars in that folder will become automatic modules (if they are not already explicitly named modules).

    Now that I see the actual command in OP, I realize that the command is incorrect because putting a folder name containing a jar on the classpath doesn't make any sense. You need to put either a folder name containing exploded classes or put the jarFileName on the classpath.

     
    Simon Roberts
    Author
    Posts: 278
    11
    Scala IntelliJ IDE Netbeans IDE Python Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:

    Simon Roberts wrote:

    Paul Anilprem wrote:

    Anil Philip wrote:

    If, as Stefan said, you can have both -p and -cp together, then can code in the module moduleName access the non-modularized jars in jarFolderName ?


    Yes, but only if it is an automatic module.



    Except that the example here asks about "modularized jars in jarFolderName" -- and jarFolderName is on the classpath, *not* the module path, so they're not going to be automatic modules, and the above will not work.


    [...]
    Now that I see the actual command in OP, I realize that the command is incorrect because putting a folder name containing a jar on the classpath doesn't make any sense. You need to put either a folder name containing exploded classes or put the jarFileName on the classpath.
     



    Oh yes, I missed that. My point was that a modular jar on the classpath is not a module, it's a jar. And an automatic module only happens when anon modular jar is placed on modulepath.

    So this fails in both intent and specific syntax.
     
    Anil Philip
    Ranch Foreman
    Posts: 466
    1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:
    Now that I see the actual command in OP, I realize that the command is incorrect because putting a folder name containing a jar on the classpath doesn't make any sense. You need to put either a folder name containing exploded classes or put the jarFileName on the classpath.



    Thanks for the correction!
     
    I will suppress my every urge. But not this shameless plug:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic