Page 1 of 1

About Question enthuware.ocpjp.ii.v11.2.3431 :

Posted: Wed Sep 04, 2019 4:08 pm
by dongyingname
Can a jar that owns module-info still becomes a unnamed module?

Option 3:
Just add an empty module-info.java to the jar.
What if the jar is placed on classpath and becomes a unnamed module, which implicitly exports all its packages?

And
Option 2:
Just add module-info to the jar with export clauses for both the packages.
In this case, the library becomes a named module. For all the groups of the company to use it they now have to explicitly requires boundanalytics, don't they? Or is the jar placed on classpass again?

If the answer to my first question is "yes", then option 2 and option 3 are both correct.

I don't know if I am asking these question correctly, as my knowledge of Module is a mess now.
Hope someone can help me answer these questions and clear things up.

Re: About Question enthuware.ocpjp.ii.v11.2.3431 :

Posted: Wed Sep 04, 2019 11:57 pm
by admin
Packages contained in a jar present on classpath can only accessed by automatic modules. So, if you put a jar on classpath, its packages still can't be accessed by named modules.

>For all the groups of the company to use it they now have to explicitly requires boundanalytics, don't they?
Yes, of course, but that is only if they are themselves using modules. Otherwise, regular non-modular applications can keep using the modular jar as before. There is no impact.

You can go through the modules chapter of this book to get the fundamentals required for this exam.

Re: About Question enthuware.ocpjp.ii.v11.2.3431 :

Posted: Sat Apr 10, 2021 10:58 pm
by ardurn
The question mentions a package com.abc.bonds, but the option "Split the jar into two modules" mentions the package com.abc.bond without s in the end. I assume this is a typo?

Re: About Question enthuware.ocpjp.ii.v11.2.3431 :

Posted: Sun Apr 11, 2021 10:55 pm
by admin
Right. It should be bonds. Fixed.
thank you for your feedback!

Re: About Question enthuware.ocpjp.ii.v11.2.3431 :

Posted: Sat Mar 25, 2023 4:34 pm
by soncrash
I really don't like the vague naming in the answers, because I don't know if you want trick me or not.

I mean the possible answer here:

"Just add module-info to the jar with export clauses for both the packages." It is not module-info but "module-info.java", it is not export, but "exports" clauses.

On the other side this question also could be acceptable: Just add an empty module-info.java to the jar - here we don't have vague naming.

In this case the jar also becomes a named module, but it won't export any packages to the other modular jars, but I don't know if I should assume that module jar will be placed on classpath or not - if yes it does not matter that it does not export any packages 3rd party applications will still see the contents of migrated jar.

Re: About Question enthuware.ocpjp.ii.v11.2.3431 :

Posted: Sat Mar 25, 2023 10:31 pm
by admin
1. That's a fair point. The option has now been updated to say "module-info.java" and "exports".

2. The problem statement says that you want to modularize the jar. It implies that you actually do want to create a valid logically sensible module. Since the two packages in the jar are the ones used by others, it makes sense to export them. If you are just adding an empty module-info.jar, you are not really modularizing the jar in the true sense. Why would you even want to put module-info.java if you expect the jar to be always put on classpath?
The whole point of modularizing is so that others who want to use modular code can use your jar in a modular way i.e. by putting it on the module-path.