Review request: jar tool to transform a plain jar file to a modular jar

[Xueming Shen]

Comments on the sun.tools.jar.Main

(1) #197-#201
      Shouldn't the "equals" be the "ignore case equals"?

(2) #202-#214
      The code might be better(?) organized as
       if (moduled != null) {
           if (mif != nuill) {
               ...
               return false;
           }
           ....
       }

(3) It might be better to move the addModuleRequires() functionality into
       ModuleInfo implementation? in which it can simply take a Manifest 
object
       and take whatever info it might need from the manifest to create the
       new ModuleInfo object. The sun.tools.jar.Main might not want to 
know the
       details of how to transfer the necessary from a Manifest to a 
ModuleInfo.
       For example, later you might find you would need an additional 
attribute
       from a existing Manifest, ideally you should be able to simply 
update the
       ModuleInfo implementation, without touching the 
sun.tools.jar.Main (the
       minfo.write(zos) will take care of the writing...)

(4) With the migration of new try-resource in getJarPath(), the code 
might look
      much better by simply do

      if (man == null)
          return files;
      ...
      if (value == null)
           return files

       And we probably don't need check if (rt != null)
       new JarFile() should never return null, it will through an 
IOException if it
       fails.

-Sherman



On 08/30/2011 04:29 PM, Mandy Chung wrote:
>  Updated webrev:
>     http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/modularize-jar.01/
>
> To modularize an existing jar file:
> 1. use 'I' flag to specify the module name
>
>   $ jar ufI astro.jar org.astro at 2.0
>
>   $ jar tvf astro.jar
>       0 Tue Aug 30 16:15:04 PDT 2011 META-INF/
>     74 Tue Aug 30 16:15:04 PDT 2011 META-INF/MANIFEST.MF
>       0 Tue Aug 30 16:15:00 PDT 2011 org/
>       0 Tue Aug 30 16:15:00 PDT 2011 org/astro/
>  276 Tue Aug 30 16:15:00 PDT 2011 org/astro/World.class
>   172 Tue Aug 30 16:21:26 PDT 2011 module-info.class<---- newly generated
>
> 2. add module-info.class to the jar file as an input file
>
>   $ jar uf greetings.jar -C modules/com.greetings module-info.class
>
> Installing a modular JAR file in the module library
>     $ jmod install greetings.jar astro.jar -L mlib
>
> Run in module mode
>     $ java -L mlib -m com.greetings
>
> Details:
> The jar tool provides a new option to transform a plain old JAR file
> into a modular JAR:
>    -I {module-name at version}
>       Generate "module-info.class" entry in the JAR file [a]
>
> It is designed to handle simple cases that:
>    * requires the default Java platform module [b]
>    * exports all public types
>    * main entry point as specified in the manifest or in the 'e'
>      flag, if any
>    * infers the dependencies from 'Class-Path' attribute if it is
>      a modular JAR file, and the specific module name of
>      that version will be added in the module dependency [c].
>
> The jar tool will determine if the inputfiles include a
> "module-info.class" entry that indicates that it is a modular
> application [d].  If exists, 'I' flag cannot be specified.
>
> Implementation: I use the classfile library that Jon Gibbons wrote
> to generate the module-info.class.  Since Jon will be updating
> javac and classfile per the module-info spec [3], I modified
> ModuleExport_attribute and ModuleRequires_attribute classes in
> a simple way but the right change will come when they are updated
> per the proposed spec.
>
> Footnotes:
> [a] jarfile name tends to be unnamed or contains '-' character.
>     The module name will not be inferred from the jarfile name.
> [b] Private and internal APIs in the jdk are not exported.
>     If the JAR file depends on any of these APIs and running
>     in module mode, this will result in a runtime error.
> [c] If the path listed in the 'Class-Path' attribute is not a
>     modular JAR, it will simply issue a warning and continue.
>     Module dependencies may be incomplete in this case.
> [d] If an application has been modularized, module-info.java that
>     describes the module definition is placed in the root of the
>     source tree and compiled in the same destination directory as
>     its classes.
>
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-August/001452.html