A company has an existing Java 8 jar file, sales-app-1.1.1.jar, that uses several Apache open source jar files that have not been modularized.
Which module-info.java file should be used to convert sales-app-1.1.jar to a module?
A company has an existing Java 8 jar file, sales-app-1.1.1.jar, that uses several Apache open source jar files that have not been modularized.
Which module-info.java file should be used to convert sales-app-1.1.jar to a module?
To convert the sales-app-1.1.jar file to a module, the module-info.java file must include the necessary dependencies using the correct module names. For Apache open source jars that have automatic module names specified in their manifests, such as org.apache.commons.collections4, org.apache.commons.lang3, and org.apache.commons.text, we use these specified names. For commons-beanutils-1.9.3.jar, which does not have an automatic module name, the module name is derived by removing the version number, replacing hyphens with dots, resulting in commons.beanutils. Therefore, the module-info.java file should be: module com.company.sales_app { requires commons.beanutils; requires org.apache.commons.collections4; requires org.apache.commons.lang3; requires org.apache.commons.text; }.
The correct answer is B. The module-info.java file should specify the dependencies of the sales-app-1.1.jar module using the requires keyword. The names of the required modules should match the names specified by the Automatic-Module-Name entries in the manifest files of the Apache open source jar files. For example, commons-collections-4.4.2.jar specifies its module name as org.apache.commons.collections4, so the module-info.java file should include a requires org.apache.commons.collections4; statement. The commons-beanutils-1.9.3.jar file does not have an Automatic-Module-Name entry, so its module name is derived from its filename by removing the version number and replacing hyphens with dots, resulting in org.apache.commons.beanutils.
f commons.beanutils does not have an automatic-module-name, you should use the actual JAR file name as the module name. In that case, option A would be the correct one: A. module com.company.sales_app { requires commons.beanutils; requires org.apache.commons.collections4; requires org.apache.commons.lang3; requires org.apache.commons.text; } So, if commons.beanutils does not have an automatic-module-name, option A is the correct choice for modularizing the sales-app-1.1.1.jar file.
When you use a non modular jar file as an automatic module, the name of the jar file is used to formulate the module name for that module. You need to know the following two basic rules while deriving this name from the file name: 1. The dashs are converted to dots and the version information and the file extension present in the file name are ignored. Therefore, for example, the module name for commons-beanutils-1.9.jar will be commons.beanutils. 2. If the jar file's manifest contains the Automatic-Module-Name entry, then that value is used as the module name (the name of the jar file is ignored completely). Therefore, in the given problem statement, module name for commons-collections4-4.0.jar will be org.apache.commons.collections4.
hence "A" is correct module com.company.sales_app { requires commons.beanutils; requires org.apache.commons.collections4; requires org.apache.commons.lang3; requires org.apache.commons.text; }
A is correct. Everybody seems to disagree but the last have a module name defined. So these will be chosen. The common-beanutils does not so it's jar file name will be stripped from its version number and the '-' will be replaced by a '.'
A is correct, requires package name of automatic modules + requieres libname not modular and rules of nameconvention (remove - . and nro of version)
tested: B
A. We assume that all files are on the module path. That means that automatic modules are generated for all of them. Otherwise, a named module cannot use them as a unnamed module in a requires directive. Then, we apply the rules for name convertion.
C is correct answer