Please rview simple clean up of the modules build for javac

[Mandy Chung]

Jonathan Gibbons wrote:
> Mandy,
>
> The comment about rmic was not directed at your work on providing 
> modules for rmic, but just a general comment on the implementation 
> technique for new rmic.   JSR 269 provides a much better tool-time API 
> for class introspection than does javadoc.

I understand.  I want to keep track of what dependency can be eliminated 
(file a CR) so that we won't forget.  Am I right that switching to use 
the JSR 269 API will eliminate the rmic -> javadoc dependency?
>
> As for module names, we're making up the conventions as we go along 
> here. I'd suggest using any name that is easy to change if we don't 
> like it. Any non-empty qualifying name is better than no 
> qualification.  One suggestion would be to use "jre." for anything 
> previously in rt.jar, and "jdk." for anything previously in tools.jar, 
> because the tools are precisely what defines the difference between 
> the jre and jdk products.

Yes, we need to define the difference between jre and jdk modules.  
"jre." and "jdk." are a good start.

Mandy
>
> -- Jon
>
>
>
> Mandy Chung wrote:
>> Jonathan Gibbons wrote:
>>> Mandy,
>>>
>>> make/modules/Makefile
>>>
>>> 185         $(HOST_JMOD_CMD) create -N -L $(JIGSAW_MODULE_LIB) ; \
>>>
>>> Can this line be deleted -- the library should have been created by 
>>> the prep-module-lib target
>>>
>>
>> Thanks for catching it.  Deleted now.
>>> make/modules/modules.config
>>> com.sun.tools.javac.Launcher should be ignored.   Please exclude it 
>>> from the javac module and do not include it in any other module.
>>>
>> Ok.
>>> I find it somewhat non-intuitive that the various individual 
>>> langtools tools (javac, javadoc, etc) depend on something called 
>>> "jdk.langtools".  To me, "jdk.langtools" sounds more like a module 
>>> that provides all the individual tools.
>>
>> It contains the runtime support for the tools.   Any suggestion on 
>> the module name?
>>
>>>
>>> I am not surprised to see a dependency on apt, although I did not 
>>> previously know that such a dependency existed.
>>>
>>> It is "disappointing" to see "new rmic" being based on javadoc API 
>>> and not on JSR 269.
>>>
>> In other words, such dependency is not desirable and should be 
>> eliminated by replacing the static reference to use JSR 269, right?
>>
>>> I am surprised to see so many unqualified module names. Do we not 
>>> expect folk to use qualified module names, and should we not lead 
>>> the way by prefixing module names with some suitable "j" word?
>>>
>>
>> The names of the jdk modules are yet to be finalized.   For the 
>> runtime modules (i.e. classes from rt.jar), their names are qualified 
>> names (currently they are prefixed by either "jdk." or "sun.").  The 
>> modules with unqualified module names are the non-runtime modules 
>> (such as javac, apt, and other jdk tools).   Is there a guideline or 
>> convention for the module names?
>>
>> Mandy
>>
>>> -- Jon
>>>
>>>
>>> Mandy Chung wrote:
>>>> Hi Jon,
>>>>
>>>> I made some minor fixes to the modules build per our discussion
>>>> of the new javac change to interface with the jigsaw resolver.
>>>>
>>>> Webrev:
>>>>  http://cr.openjdk.java.net/~mchung/jigsaw/misc-cleanup/
>>>>
>>>> 1. make/modules/tools/Makefile to use JAVAC_CMD instead of 
>>>> HOST_JAVAC_CMD. - JAVAC_CMD is the hybrid javac building jdk and we 
>>>> should
>>>>  not need to use HOST_JAVAC_CMD.
>>>>
>>>> 2. make/modules/Makefile
>>>>
>>>> - refactor the system module library creation as a new target
>>>> - when HOST_JAVAC_CMD is called to compile module-info.java,
>>>>  the default system module library is already created
>>>>
>>>> 3. modules.config and modules.group change
>>>>
>>>> - this is a follow-up to the email thread about tools in 
>>>>  modules.config [1]
>>>> - javac, javap, javah, javadoc, and apt classes now live
>>>>  in its own module (each tool is a single module).
>>>>  Also, com.sun.tools.javac.Launcher class is moved to the
>>>>  deprecated.tools module.
>>>>
>>>> Here are the dependencies among these langtools modules:
>>>>
>>>> apt -> javac
>>>> apt -> jdk.langtools
>>>> javac -> jdk.langtools
>>>> javac -> jdk.logging
>>>> javadoc -> javac
>>>> javadoc -> jdk.langtools
>>>> javadoc -> jdk.xml
>>>> javah -> javac
>>>> javah -> jdk.langtools
>>>> javap -> javac
>>>> javap -> jdk.langtools
>>>>
>>>> There is a dependency from JAXWS to apt:
>>>>   jaxws.tools -> apt
>>>>
>>>> com.sun.tools.internal.ws.wscompile.WsgenTool -> 
>>>> com.sun.tools.apt.Main (apt)
>>>>
>>>> Do you expect such dependency to apt?
>>>>
>>>> - rmi.tools module is merged with the rmic module.
>>>>
>>>>
>>>> There exists a new rmic (sun.rmi.rmic.newrmic package) that
>>>> depends on javac and javadoc.  The new rmic is launched from rmic 
>>>> -Xnew option.
>>>>
>>>> rmic -> javac
>>>> rmic -> javadoc
>>>>
>>>> For your reference, the dependencies are:
>>>> sun.rmi.rmic.newrmic.BatchEnvironment    -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.BatchEnvironment    -> com.sun.javadoc.RootDoc 
>>>> (javadoc)
>>>> sun.rmi.rmic.newrmic.Generator           -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.Main                -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.Main                -> com.sun.javadoc.RootDoc 
>>>> (javadoc)
>>>> sun.rmi.rmic.newrmic.Main                -> 
>>>> com.sun.tools.javac.Main (javac)
>>>> sun.rmi.rmic.newrmic.Main                -> 
>>>> com.sun.tools.javadoc.Main (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.JrmpGenerator  -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass    -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass    -> 
>>>> com.sun.javadoc.MethodDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass$ClassDocComparator -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass$Method -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass$Method -> 
>>>> com.sun.javadoc.MethodDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass$Method -> 
>>>> com.sun.javadoc.Parameter (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.RemoteClass$Method -> 
>>>> com.sun.javadoc.Type (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.StubSkeletonWriter -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.StubSkeletonWriter -> 
>>>> com.sun.javadoc.MethodDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.StubSkeletonWriter -> 
>>>> com.sun.javadoc.Type (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.Util           -> 
>>>> com.sun.javadoc.ClassDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.Util           -> 
>>>> com.sun.javadoc.MethodDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.Util           -> 
>>>> com.sun.javadoc.PackageDoc (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.Util           -> 
>>>> com.sun.javadoc.Parameter (javadoc)
>>>> sun.rmi.rmic.newrmic.jrmp.Util           -> com.sun.javadoc.Type 
>>>> (javadoc)
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>>>
>>>> [1] 
>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000664.html 
>>>>
>>>>
>>>>
>>>
>>
>