From Kelly.Ohair at sun.com  Thu Apr  1 10:09:57 2010
From: Kelly.Ohair at sun.com (Kelly O'Hair)
Date: Thu, 1 Apr 2010 10:09:57 -0700
Subject: Use jdk-module-image as boot jdk (modules build +
	SKIP_BOOT_CYCLE=false)
In-Reply-To: <4BB3D7A3.2090409@Sun.com>
References: <4BB3D7A3.2090409@Sun.com>
Message-ID: <A1988263-023A-45E5-9D92-D52FBA628049@Sun.COM>


On Mar 31, 2010, at 4:15 PM, Mandy Chung wrote:

> Kelly, Alan, Karen,
>
> Jon and I have been discussing the testing for the new javac change  
> and modules image.   Building JDK itself is one the the simplest and  
> most effective tests that Jon typically uses to validate javac  
> changes (by building JDK with SKIP_BOOT_CYCLE=false).
>
> Currently, "make SKIP_BOOT_CYCLE=false all" will first build a  
> legacy jdk image and set it as the ALT_BOOTDIR to rebuild the jdk.   
> As Jon suggests, for modules build, SKIP_BOOT_CYCLE=false should use  
> the jdk-module-image as the ALT_BOOTDIR to rebuild the jdk modules.
>
> This fix makes changes in the top level repo, jdk, hotspot, and  
> corba repository as follows:
>
> 1. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/top-repo
>
>  - Set JDK_IMAGE_NAME to j2sdk-image for legacy image build or
>    jdk-module-image for modules image build.
>  - not to create j2sdk-image for modules build (a bug Jon reported)
>
> 2. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/jdk
>
>  - minor cleanup such as using absolute path of the modules directory
>  - Add OTHER_JAVAHFLAGS that will be used to set classpath
>    to look up pkcs11 and mscapi classes from a temp directory
>  - Add the logics to import from the modules instead of rt.jar and  
> resources.jar
>    Eventually we should import modules instead of copying in the  
> classes.
>  - eliminate the second build of the make/modules/Makefile
>    Modules.gmk to invoke make/modules/Makefile build was needed
>    so as to make sure the jdk modules in the "modules" directory
>    are up-to-date.  However, this is only needed for jdk developers  
> who
>    is doing incremental builds after the jdk is modularized.  Like  
> the images
>    build taking the current content from the "classes" directory, it  
> will just
>    take the current content in the "modules" directory to build the  
> modules
>    images.  For incremental builds, the jdk developers need to make
>    sure the jdk modules are up-to-date.  I'll also come up with some
>    better way to make our life easier in updating the jdk-module- 
> image.
>
> 3. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/corba/
>
>   - corba, for some reason, links with libjvm.so and  
> libjava.so.      The fix is to include the new library path of the  
> jdk-module-image.
>     This will need to change when we move the native libraries to
>     the module content.
>
> 4. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/
>
>   - The makefile checks if the tools.jar exists for building SA.  In  
> the modular
>     world, it no longer has the tools.jar.
>

In both:

http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/linux/vm/os_linux.cpp.sdiff.html

http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/solaris/vm/os_solaris.cpp.sdiff.html

I'm concerned that the 'buf' character array might overflow.
Just asking, I didn;t have the time to walk through all of this.

> An open issue:  the jaxp and jaxws build may download the source  
> bundles.
> With using jdk-module-image as the boot jdk, jaxp and jaxws build will
> set ANT_JAVA_HOME to the jdk-module-image that will fail the download
> as security/crypto support in the modules image is an open issue.
>
> Caused by: java.lang.SecurityException: Can not initialize  
> cryptographic mechanism^M
>       at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86)^M
>
> I'd like to push this set of changes in jigsaw althought there is  
> the jaxp and jaxws
> bundle download issue.  As long as there is a local downloaded copy  
> of the
> jaxp/jaxws bundle, it will build fine.

Inside SWAN, it should find the jaxp/jaxws bundles in /java/devtools/ 
share/jdk7-drops,
and with JPRT, I think it should find these copies from my /java/ 
devtools copy at
/opt/jprt/slashjava/devtools/share/jdk7-drops

How these source drop bundles are found is a continued issue for me,  
and when it
goes wrong, like Rama found out recently, and the ant script trys to  
download from
some foreign http: download site, the ant scripts seem to seize up on  
the JPRT clients
and all hell breaks loose. :^(    Just a warning, but your builds  
should be ok.

-kto

>
> Thanks
> Mandy



From jonathan.gibbons at sun.com  Thu Apr  1 10:09:33 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 01 Apr 2010 17:09:33 +0000
Subject: hg: jigsaw/jigsaw/langtools: 27 new changesets
Message-ID: <20100401171027.1287D44D02@hg.openjdk.java.net>

Changeset: 6eca0895a644
Author:    jjg
Date:      2010-02-23 18:43 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6eca0895a644

6511613: javac unexpectedly doesn't fail in some cases if an annotation processor specified
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/processing/6511613/DummyProcessor.java
+ test/tools/javac/processing/6511613/clss41701.java

Changeset: 87eb6edd4f21
Author:    jjg
Date:      2010-02-25 09:42 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/87eb6edd4f21

4880220: Add a warning when accessing a static method via an reference
Reviewed-by: darcy

! make/build.properties
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/4880220/T4880220.empty.out
+ test/tools/javac/4880220/T4880220.error.out
+ test/tools/javac/4880220/T4880220.java
+ test/tools/javac/4880220/T4880220.warn.out

Changeset: 85242c273d31
Author:    darcy
Date:      2010-02-25 11:04 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/85242c273d31

6929645: Address various findbugs warnings in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java

Changeset: dbcba45123cd
Author:    jjg
Date:      2010-02-25 12:26 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/dbcba45123cd

6929544: langtools source code uses statics qualified by instance variables
Reviewed-by: darcy

! make/build.properties
! src/share/classes/com/sun/tools/apt/main/CommandLine.java
! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java
! src/share/classes/com/sun/tools/doclets/standard/Standard.java
! src/share/classes/com/sun/tools/javac/Launcher.java
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
! src/share/classes/com/sun/tools/javac/main/CommandLine.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java

Changeset: af75fd6155de
Author:    jjg
Date:      2010-02-25 13:32 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/af75fd6155de

6893943: exit code from javah with no args is 0
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
+ test/tools/javah/T6893943.java

Changeset: b030706da5b4
Author:    jjg
Date:      2010-02-26 08:42 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b030706da5b4

6881645: Unchecked method call on a method declared inside anonymous inner causes javac to crash
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/T6881645.java

Changeset: 72833a8a6086
Author:    jjg
Date:      2010-02-26 15:26 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/72833a8a6086

6930076: "null" can incorrectly appear in error message compiler.err.error.reading.file
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/Paths.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java

Changeset: 7b69c7083a97
Author:    jjg
Date:      2010-02-26 15:30 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/7b69c7083a97

6930032: fix findbugs errors in com.sun.tools.javac.comp
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java

Changeset: 7c23bbbe0dbd
Author:    darcy
Date:      2010-03-02 14:06 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/7c23bbbe0dbd

6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java

Changeset: 6e1e2738c530
Author:    jjg
Date:      2010-03-02 16:40 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6e1e2738c530

6931482: minor findbugs fixes
Reviewed-by: darcy

! src/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java

Changeset: 235135d61974
Author:    jjg
Date:      2010-03-02 16:43 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/235135d61974

6931127: strange test class files
Reviewed-by: darcy

! test/tools/javac/annotations/neg/Constant.java
! test/tools/javac/generics/Casting.java
! test/tools/javac/generics/Casting3.java
! test/tools/javac/generics/Casting4.java
! test/tools/javac/generics/InnerInterface1.java
! test/tools/javac/generics/InnerInterface2.java
! test/tools/javac/generics/Multibound1.java
! test/tools/javac/generics/MultipleInheritance.java
! test/tools/javac/generics/NameOrder.java
! test/tools/javac/generics/PermuteBound.java
! test/tools/javac/generics/PrimitiveVariant.java

Changeset: fc7132746501
Author:    darcy
Date:      2010-03-03 16:05 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/fc7132746501

6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ test/tools/javac/processing/model/element/TestAnonClassNames.java
+ test/tools/javac/processing/model/element/TestAnonSourceNames.java

Changeset: 7f5db2e8b423
Author:    jjg
Date:      2010-03-03 17:22 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/7f5db2e8b423

6931927: position issues with synthesized anonymous class
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/tree/TestAnnotatedAnonClass.java
+ test/tools/javac/tree/TreePosTest.java
- test/tools/javac/treepostests/TreePosTest.java

Changeset: 117c95448ab9
Author:    jjg
Date:      2010-03-03 19:34 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/117c95448ab9

6931126: jtreg tests not Windows friendly
Reviewed-by: darcy

! test/tools/javac/ThrowsIntersection_1.java
! test/tools/javac/ThrowsIntersection_2.java
! test/tools/javac/ThrowsIntersection_3.java
! test/tools/javac/ThrowsIntersection_4.java
! test/tools/javac/generics/NameOrder.java

Changeset: c55733ceed61
Author:    lana
Date:      2010-03-04 13:40 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c55733ceed61

Merge


Changeset: a23282f17d0b
Author:    jjg
Date:      2010-03-05 16:12 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a23282f17d0b

6930108: IllegalArgumentException in AbstractDiagnosticFormatter for tools/javac/api/TestJavacTaskScanner.jav
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! test/tools/javac/api/TestJavacTaskScanner.java
+ test/tools/javac/api/TestResolveError.java

Changeset: a4f3b97c8028
Author:    jjg
Date:      2010-03-05 16:13 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a4f3b97c8028

Merge


Changeset: 9871ce4fd56f
Author:    jjg
Date:      2010-03-10 16:23 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9871ce4fd56f

6933914: fix missing newlines
Reviewed-by: ohair

! test/tools/javac/OverrideChecks/6738538/T6738538a.java
! test/tools/javac/OverrideChecks/6738538/T6738538b.java
! test/tools/javac/api/6731573/Erroneous.java
! test/tools/javac/api/6731573/T6731573.java
! test/tools/javac/cast/6548436/T6548436d.java
! test/tools/javac/cast/6558559/T6558559a.java
! test/tools/javac/cast/6558559/T6558559b.java
! test/tools/javac/cast/6586091/T6586091.java
! test/tools/javac/enum/T6724345.java
! test/tools/javac/generics/T6557954.java
! test/tools/javac/generics/T6751514.java
! test/tools/javac/generics/T6869075.java
! test/tools/javac/generics/inference/6569789/T6569789.java
! test/tools/javac/generics/inference/6650759/T6650759a.java
! test/tools/javac/generics/wildcards/T6732484.java
! test/tools/javac/processing/model/util/elements/Foo.java
! test/tools/javac/varargs/T6746184.java
- test/tools/javap/T6305779.java
! test/tools/javap/T6715251.java
! test/tools/javap/T6715753.java

Changeset: f856c0942c06
Author:    jjg
Date:      2010-03-12 12:00 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f856c0942c06

6934224: update langtools/test/Makefile
Reviewed-by: ohair

! make/jprt.properties
! test/Makefile

Changeset: b816baf594e3
Author:    mikejwre
Date:      2010-03-04 13:50 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b816baf594e3

Added tag jdk7-b85 for changeset 136bfc679462

! .hgtags

Changeset: ef07347428f2
Author:    lana
Date:      2010-03-09 15:29 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ef07347428f2

Merge

- test/tools/javac/treepostests/TreePosTest.java

Changeset: 6fad35d25b1e
Author:    lana
Date:      2010-03-18 18:52 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6fad35d25b1e

Merge


Changeset: dd30de080cb9
Author:    jjg
Date:      2010-03-23 18:05 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/dd30de080cb9

6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used  output of javap is changed
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javap/ClassWriter.java
+ test/tools/javap/6937244/T6937244.java
+ test/tools/javap/6937244/T6937244A.java

Changeset: 3058880c0b8d
Author:    jjg
Date:      2010-03-24 12:18 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3058880c0b8d

6937318: jdk7 b86:  javah and javah -help is no output for these commands
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
! test/tools/javah/T6893943.java

Changeset: 65e422bbb984
Author:    darcy
Date:      2010-03-24 17:02 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/65e422bbb984

6937417: javac -Xprint returns IndexOutOfBoundsException
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java
+ test/tools/javac/processing/model/util/elements/VacuousEnum.java

Changeset: de6375751eb7
Author:    ohair
Date:      2010-03-26 22:37 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/de6375751eb7

6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now
Reviewed-by: jjg

! make/Makefile

Changeset: e2879c758bac
Author:    jjg
Date:      2010-04-01 10:07 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/e2879c758bac

Track TL/langtools changes, including workaround for using Ant 1.8.0

! .hgtags
! src/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/Paths.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
- test/tools/javac/treepostests/TreePosTest.java
- test/tools/javap/T6305779.java



From jonathan.gibbons at oracle.com  Thu Apr  1 10:14:43 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 01 Apr 2010 10:14:43 -0700
Subject: Use jdk-module-image as boot jdk (modules build +
	SKIP_BOOT_CYCLE=false)
In-Reply-To: <A1988263-023A-45E5-9D92-D52FBA628049@Sun.COM>
References: <4BB3D7A3.2090409@Sun.com>
	<A1988263-023A-45E5-9D92-D52FBA628049@Sun.COM>
Message-ID: <4BB4D483.10207@oracle.com>

Kelly O'Hair wrote:
>
> On Mar 31, 2010, at 4:15 PM, Mandy Chung wrote:
>
>> Kelly, Alan, Karen,
>>
>> Jon and I have been discussing the testing for the new javac change 
>> and modules image.   Building JDK itself is one the the simplest and 
>> most effective tests that Jon typically uses to validate javac 
>> changes (by building JDK with SKIP_BOOT_CYCLE=false).
>>
>> Currently, "make SKIP_BOOT_CYCLE=false all" will first build a legacy 
>> jdk image and set it as the ALT_BOOTDIR to rebuild the jdk.  As Jon 
>> suggests, for modules build, SKIP_BOOT_CYCLE=false should use the 
>> jdk-module-image as the ALT_BOOTDIR to rebuild the jdk modules.
>>
>> This fix makes changes in the top level repo, jdk, hotspot, and corba 
>> repository as follows:
>>
>> 1. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/top-repo
>>
>>  - Set JDK_IMAGE_NAME to j2sdk-image for legacy image build or
>>    jdk-module-image for modules image build.
>>  - not to create j2sdk-image for modules build (a bug Jon reported)
>>
>> 2. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/jdk
>>
>>  - minor cleanup such as using absolute path of the modules directory
>>  - Add OTHER_JAVAHFLAGS that will be used to set classpath
>>    to look up pkcs11 and mscapi classes from a temp directory
>>  - Add the logics to import from the modules instead of rt.jar and 
>> resources.jar
>>    Eventually we should import modules instead of copying in the 
>> classes.
>>  - eliminate the second build of the make/modules/Makefile
>>    Modules.gmk to invoke make/modules/Makefile build was needed
>>    so as to make sure the jdk modules in the "modules" directory
>>    are up-to-date.  However, this is only needed for jdk developers who
>>    is doing incremental builds after the jdk is modularized.  Like 
>> the images
>>    build taking the current content from the "classes" directory, it 
>> will just
>>    take the current content in the "modules" directory to build the 
>> modules
>>    images.  For incremental builds, the jdk developers need to make
>>    sure the jdk modules are up-to-date.  I'll also come up with some
>>    better way to make our life easier in updating the jdk-module-image.
>>
>> 3. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/corba/
>>
>>   - corba, for some reason, links with libjvm.so and libjava.so.      
>> The fix is to include the new library path of the jdk-module-image.
>>     This will need to change when we move the native libraries to
>>     the module content.
>>
>> 4. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/
>>
>>   - The makefile checks if the tools.jar exists for building SA.  In 
>> the modular
>>     world, it no longer has the tools.jar.
>>
>
> In both:
>
> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/linux/vm/os_linux.cpp.sdiff.html 
>
>
> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/solaris/vm/os_solaris.cpp.sdiff.html 
>
>
> I'm concerned that the 'buf' character array might overflow.
> Just asking, I didn;t have the time to walk through all of this.
>
>> An open issue:  the jaxp and jaxws build may download the source 
>> bundles.
>> With using jdk-module-image as the boot jdk, jaxp and jaxws build will
>> set ANT_JAVA_HOME to the jdk-module-image that will fail the download
>> as security/crypto support in the modules image is an open issue.
>>
>> Caused by: java.lang.SecurityException: Can not initialize 
>> cryptographic mechanism^M
>>       at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86)^M
>>
>> I'd like to push this set of changes in jigsaw althought there is the 
>> jaxp and jaxws
>> bundle download issue.  As long as there is a local downloaded copy 
>> of the
>> jaxp/jaxws bundle, it will build fine.
>
> Inside SWAN, it should find the jaxp/jaxws bundles in 
> /java/devtools/share/jdk7-drops,
> and with JPRT, I think it should find these copies from my 
> /java/devtools copy at
> /opt/jprt/slashjava/devtools/share/jdk7-drops
>
> How these source drop bundles are found is a continued issue for me, 
> and when it
> goes wrong, like Rama found out recently, and the ant script trys to 
> download from
> some foreign http: download site, the ant scripts seem to seize up on 
> the JPRT clients
> and all hell breaks loose. :^(    Just a warning, but your builds 
> should be ok.
>
> -kto
>
>>
>> Thanks
>> Mandy
>


Kelly,

Would it possible to specify that the makefiles should never do this 
sort of downloading?  If the user believes that the build should have 
access to locally installed bundles, it would be better for the makefile 
to fail, reporting that the assumption is incorrect, instead of having 
the makefiles struggle gamely on, trying to find the bundles wherever it 
can.

I'm not saying it should never attempt to locate them; I'm just 
suggesting it should be possible to disable this behavior.

-- Jon


From Kelly.Ohair at sun.com  Thu Apr  1 10:22:48 2010
From: Kelly.Ohair at sun.com (Kelly O'Hair)
Date: Thu, 1 Apr 2010 10:22:48 -0700
Subject: Use jdk-module-image as boot jdk (modules build +
	SKIP_BOOT_CYCLE=false)
In-Reply-To: <4BB4D483.10207@oracle.com>
References: <4BB3D7A3.2090409@Sun.com>
	<A1988263-023A-45E5-9D92-D52FBA628049@Sun.COM>
	<4BB4D483.10207@oracle.com>
Message-ID: <B4682B64-0750-46BA-AD66-B84E2BD2F8F9@Sun.COM>


On Apr 1, 2010, at 10:14 AM, Jonathan Gibbons wrote:

> Kelly O'Hair wrote:
>>
>> On Mar 31, 2010, at 4:15 PM, Mandy Chung wrote:
>>
>>> Kelly, Alan, Karen,
>>>
>>> Jon and I have been discussing the testing for the new javac  
>>> change and modules image.   Building JDK itself is one the the  
>>> simplest and most effective tests that Jon typically uses to  
>>> validate javac changes (by building JDK with SKIP_BOOT_CYCLE=false).
>>>
>>> Currently, "make SKIP_BOOT_CYCLE=false all" will first build a  
>>> legacy jdk image and set it as the ALT_BOOTDIR to rebuild the  
>>> jdk.  As Jon suggests, for modules build, SKIP_BOOT_CYCLE=false  
>>> should use the jdk-module-image as the ALT_BOOTDIR to rebuild the  
>>> jdk modules.
>>>
>>> This fix makes changes in the top level repo, jdk, hotspot, and  
>>> corba repository as follows:
>>>
>>> 1. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/top-repo
>>>
>>> - Set JDK_IMAGE_NAME to j2sdk-image for legacy image build or
>>>   jdk-module-image for modules image build.
>>> - not to create j2sdk-image for modules build (a bug Jon reported)
>>>
>>> 2. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/jdk
>>>
>>> - minor cleanup such as using absolute path of the modules directory
>>> - Add OTHER_JAVAHFLAGS that will be used to set classpath
>>>   to look up pkcs11 and mscapi classes from a temp directory
>>> - Add the logics to import from the modules instead of rt.jar and  
>>> resources.jar
>>>   Eventually we should import modules instead of copying in the  
>>> classes.
>>> - eliminate the second build of the make/modules/Makefile
>>>   Modules.gmk to invoke make/modules/Makefile build was needed
>>>   so as to make sure the jdk modules in the "modules" directory
>>>   are up-to-date.  However, this is only needed for jdk developers  
>>> who
>>>   is doing incremental builds after the jdk is modularized.  Like  
>>> the images
>>>   build taking the current content from the "classes" directory,  
>>> it will just
>>>   take the current content in the "modules" directory to build the  
>>> modules
>>>   images.  For incremental builds, the jdk developers need to make
>>>   sure the jdk modules are up-to-date.  I'll also come up with some
>>>   better way to make our life easier in updating the jdk-module- 
>>> image.
>>>
>>> 3. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/corba/
>>>
>>>  - corba, for some reason, links with libjvm.so and  
>>> libjava.so.      The fix is to include the new library path of the  
>>> jdk-module-image.
>>>    This will need to change when we move the native libraries to
>>>    the module content.
>>>
>>> 4. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/
>>>
>>>  - The makefile checks if the tools.jar exists for building SA.   
>>> In the modular
>>>    world, it no longer has the tools.jar.
>>>
>>
>> In both:
>>
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/linux/vm/os_linux.cpp.sdiff.html
>>
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/solaris/vm/os_solaris.cpp.sdiff.html
>>
>> I'm concerned that the 'buf' character array might overflow.
>> Just asking, I didn;t have the time to walk through all of this.
>>
>>> An open issue:  the jaxp and jaxws build may download the source  
>>> bundles.
>>> With using jdk-module-image as the boot jdk, jaxp and jaxws build  
>>> will
>>> set ANT_JAVA_HOME to the jdk-module-image that will fail the  
>>> download
>>> as security/crypto support in the modules image is an open issue.
>>>
>>> Caused by: java.lang.SecurityException: Can not initialize  
>>> cryptographic mechanism^M
>>>      at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86)^M
>>>
>>> I'd like to push this set of changes in jigsaw althought there is  
>>> the jaxp and jaxws
>>> bundle download issue.  As long as there is a local downloaded  
>>> copy of the
>>> jaxp/jaxws bundle, it will build fine.
>>
>> Inside SWAN, it should find the jaxp/jaxws bundles in /java/ 
>> devtools/share/jdk7-drops,
>> and with JPRT, I think it should find these copies from my /java/ 
>> devtools copy at
>> /opt/jprt/slashjava/devtools/share/jdk7-drops
>>
>> How these source drop bundles are found is a continued issue for  
>> me, and when it
>> goes wrong, like Rama found out recently, and the ant script trys  
>> to download from
>> some foreign http: download site, the ant scripts seem to seize up  
>> on the JPRT clients
>> and all hell breaks loose. :^(    Just a warning, but your builds  
>> should be ok.
>>
>> -kto
>>
>>>
>>> Thanks
>>> Mandy
>>
>
>
> Kelly,
>
> Would it possible to specify that the makefiles should never do this  
> sort of downloading?  If the user believes that the build should  
> have access to locally installed bundles, it would be better for the  
> makefile to fail, reporting that the assumption is incorrect,  
> instead of having the makefiles struggle gamely on, trying to find  
> the bundles wherever it can.
>
> I'm not saying it should never attempt to locate them; I'm just  
> suggesting it should be possible to disable this behavior.

At this point, I tend to agree. I will try and look into this.

-kto

>
> -- Jon



From mandy.chung at oracle.com  Thu Apr  1 12:07:17 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 01 Apr 2010 12:07:17 -0700
Subject: Use jdk-module-image as boot jdk (modules build +
	SKIP_BOOT_CYCLE=false)
In-Reply-To: <A1988263-023A-45E5-9D92-D52FBA628049@Sun.COM>
References: <4BB3D7A3.2090409@Sun.com>
	<A1988263-023A-45E5-9D92-D52FBA628049@Sun.COM>
Message-ID: <4BB4EEE5.9060709@oracle.com>

On 04/01/10 10:09, Kelly O'Hair wrote:
> 
> On Mar 31, 2010, at 4:15 PM, Mandy Chung wrote:

[...]

>> 4. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/
>>
>>   - The makefile checks if the tools.jar exists for building SA.  In the modular
>>     world, it no longer has the tools.jar.
>>
> 
> In both:
> 
> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/linux/vm/os_linux.cpp.sdiff.html 
> 
> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/solaris/vm/os_solaris.cpp.sdiff.html 
> 
> 
> I'm concerned that the 'buf' character array might overflow.
> Just asking, I didn;t have the time to walk through all of this.

I could clean up to use snprintf.  There are several other places in the 
VM that should handle buffer overflow.

>> An open issue:  the jaxp and jaxws build may download the source bundles.
>> With using jdk-module-image as the boot jdk, jaxp and jaxws build will
>> set ANT_JAVA_HOME to the jdk-module-image that will fail the download
>> as security/crypto support in the modules image is an open issue.
>>
>> Caused by: java.lang.SecurityException: Can not initialize 
>> cryptographic mechanism^M
>>       at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86)^M
>>
>> I'd like to push this set of changes in jigsaw although there is the jaxp and jaxws
>> bundle download issue.  As long as there is a local downloaded copy of the
>> jaxp/jaxws bundle, it will build fine.
> 
> Inside SWAN, it should find the jaxp/jaxws bundles in 
> /java/devtools/share/jdk7-drops,
> and with JPRT, I think it should find these copies from my 
> /java/devtools copy at
> /opt/jprt/slashjava/devtools/share/jdk7-drops

I ran into this issue when I built on my windows box that didn't set up 
to find these bundles.

> How these source drop bundles are found is a continued issue for me, and  when it
> goes wrong, like Rama found out recently, and the ant script trys to download from
> some foreign http: download site, the ant scripts seem to seize up on  the JPRT clients
> and all hell breaks loose. :^(    Just a warning, but your builds should 
> be ok.

Yes, my jprt job completed successfully.  BTW, I believe that this is 
not a new issue just for modules build.  When we build the legacy image 
with SKIP_BOOT_CYCLE=false from an openjdk repo, it should run into some 
download issue since the cacerts in the openjdk build is empty.

Thanks for the review.
Mandy


From Riaz.Aimandi at Sun.COM  Fri Apr  2 15:16:21 2010
From: Riaz.Aimandi at Sun.COM (Riaz A Aimandi)
Date: Fri, 02 Apr 2010 18:16:21 -0400
Subject: Module access question
Message-ID: <FDCD96C7-8AE9-4DF4-9592-A4A5255E3160@sun.com>

Hi,

I have a quick question regarding modules.

Lets say I have a module that has both API & Implementation (in  
different packages)

Is it possible to restrict access from other modules to API only (both  
at compile & runtime) ?

i.e., disallow implementation classes to be directly accessed from  
other modules.

Example:
	Module foo:
	package foo.api.* : has API
	package foo.impl.* has Implementation

	I want to restrict direct access to foo.impl.* from any module that  
requires this module.

I understand that with multiple modules this could be easily done. But  
I am hoping that I do not have to breakup modules just for this purpose.

Thanks,

- riaz


From alex.buckley at oracle.com  Fri Apr  2 15:24:03 2010
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 02 Apr 2010 15:24:03 -0700
Subject: Module access question
In-Reply-To: <FDCD96C7-8AE9-4DF4-9592-A4A5255E3160@sun.com>
References: <FDCD96C7-8AE9-4DF4-9592-A4A5255E3160@sun.com>
Message-ID: <4BB66E83.8040208@oracle.com>

Yes, just make the types in foo.impl be module-private via the "module" 
keyword. They can extend/implement the public types in foo.api, but will 
be inaccessible to types outside the foo module. Of course there will 
probably be some public factory or other entry point in foo.impl to get 
things going.

Note that the "module" accessibility level is a feature of JSR 294, but 
which types are in which module is a property of the module system you 
are using. In the RI of JSR 294, javac determines which types are in the 
"foo" module versus in other modules based on the modulepath.

Alex

On 4/2/2010 3:16 PM, Riaz A Aimandi wrote:
> Hi,
> 
> I have a quick question regarding modules.
> 
> Lets say I have a module that has both API & Implementation (in 
> different packages)
> 
> Is it possible to restrict access from other modules to API only (both 
> at compile & runtime) ?
> 
> i.e., disallow implementation classes to be directly accessed from other 
> modules.
> 
> Example:
>     Module foo:
>     package foo.api.* : has API
>     package foo.impl.* has Implementation
> 
>     I want to restrict direct access to foo.impl.* from any module that 
> requires this module.
> 
> I understand that with multiple modules this could be easily done. But I 
> am hoping that I do not have to breakup modules just for this purpose.
> 
> Thanks,
> 
> - riaz


From mandy.chung at sun.com  Fri Apr  2 23:11:35 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Sat, 03 Apr 2010 06:11:35 +0000
Subject: hg: jigsaw/jigsaw: SKIP_BOOT_CYCLE=false to use jdk-module-image for
	modules build
Message-ID: <20100403061136.6092644F34@hg.openjdk.java.net>

Changeset: 87cdb4678278
Author:    mchung
Date:      2010-04-02 23:04 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/rev/87cdb4678278

SKIP_BOOT_CYCLE=false to use jdk-module-image for modules build
Summary: zip up jdk-module-image for modules build
Reviewed-by: ohair

! Makefile
! make/jprt.gmk



From mandy.chung at sun.com  Fri Apr  2 23:11:40 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Sat, 03 Apr 2010 06:11:40 +0000
Subject: hg: jigsaw/jigsaw/corba: SKIP_BOOT_CYCLE=false to use
	jdk-module-image for modules build
Message-ID: <20100403061142.EBC7D44F35@hg.openjdk.java.net>

Changeset: 74668f4f6bea
Author:    mchung
Date:      2010-04-02 23:03 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/74668f4f6bea

SKIP_BOOT_CYCLE=false to use jdk-module-image for modules build
Summary: Add -L lib/<arch> to look for native libraries
Reviewed-by: ohair

! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/sun/corba/core/Makefile



From mandy.chung at sun.com  Fri Apr  2 23:11:50 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Sat, 03 Apr 2010 06:11:50 +0000
Subject: hg: jigsaw/jigsaw/hotspot: Use jdk-module-image to build hotspot
Message-ID: <20100403061202.E267A44F36@hg.openjdk.java.net>

Changeset: 4ac54e858f41
Author:    mchung
Date:      2010-04-02 23:08 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/4ac54e858f41

Use jdk-module-image to build hotspot
Summary: gamma launcher to look for jvm from lib/<arch> and jre/lib/<arch>
Reviewed-by: acorn, ohair

! make/linux/makefiles/sa.make
! make/solaris/makefiles/sa.make
! make/windows/makefiles/vm.make
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp



From mandy.chung at sun.com  Fri Apr  2 23:12:17 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Sat, 03 Apr 2010 06:12:17 +0000
Subject: hg: jigsaw/jigsaw/jdk: SKIP_BOOT_CYCLE=false to use jdk-module-image
	for modules build
Message-ID: <20100403061315.5D59D44F37@hg.openjdk.java.net>

Changeset: 57a86394f749
Author:    mchung
Date:      2010-04-02 23:02 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/57a86394f749

SKIP_BOOT_CYCLE=false to use jdk-module-image for modules build
Reviewed-by: ohair

! make/common/BuildPackages.gmk
! make/common/Modules.gmk
! make/common/internal/Defs-corba.gmk
! make/common/internal/Defs-jaxp.gmk
! make/common/internal/Defs-jaxws.gmk
! make/common/internal/ImportComponents.gmk
! make/common/shared/Defs-java.gmk
! make/common/shared/Defs.gmk
! make/jprt.gmk
! make/modules/Makefile
! make/sun/security/mscapi/Makefile
! make/sun/security/pkcs11/Makefile



From jonathan.gibbons at oracle.com  Sat Apr  3 14:03:08 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 03 Apr 2010 14:03:08 -0700
Subject: jigsaw builds
Message-ID: <4BB7AD0C.9030009@oracle.com>

The jigsaw modules builds do not include src.zip and the demo and sample 
directories.

Is this intentional, accidental, or just "not got around to it, yet?"

> $ ls build/linux-amd64/j2sdk-image/
> ASSEMBLY_EXCEPTION  bin  demo  include  jre  lib  LICENSE  man  
> sample  src.zip  THIRD_PARTY_README
> $ ls build/linux-amd64/jdk-module-image/
> ASSEMBLY_EXCEPTION  bin  include  lib  LICENSE  THIRD_PARTY_README

-- Jon


From jonathan.gibbons at oracle.com  Sat Apr  3 14:34:37 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 03 Apr 2010 14:34:37 -0700
Subject: jmod comments
Message-ID: <4BB7B46D.3040202@oracle.com>

There is currently a mismatch between the way that we think the Jigsaw 
tools should be used and the way we actually use them in practice.

In particular, jmod does not well serve the needs of the primary Jigsaw 
client, the JDK itself.

jmod currently assumes that the classes are laid out neatly on disk in 
separate hierarchies for each module. That's very convenient, if that is 
actually how your classes are organized, but I venture to suggest that 
with the current fine grain module scheme, the JDK classes are never 
ever going to be laid out that way. So currently, the JDK build jumps 
through hoops moving classes around after they have been built, in order 
to satisfy the jmod input requirements. The tail is definitely wagging 
the dog here.

I'm also coming at this from a similar but different perspective: 
langtools, and the as-yet-unresolved issue of -Xbootclasspath and 
incremental builds. [1]

In langtools, we currently use -J-Xbootclasspath to avoid having to 
recompile JDK every time we edit javac or other langtools tools. In a 
Jigsaw world, the replacement would seem to be to build and use a 
private module library which has a standard JDK module library as its 
parent.  Thus, -J-Xbootclasspath gets replaced by -J-L. But that just 
defers the issue one step -- I still have to build the library, with 
jmod, meaning all the classes have to be moved around into 
module-specific hierarchies, and that just seems wrong.

It would be much better if there was a way that jmod could be given 
information about what classes belong in each module. If this was an Ant 
task[2], I would expect to see something like filesets being used to 
describe the contents of each module. In the absence of an Ant task, one 
suggestion would be to provide -include and -exclude options on the 
command line to include and exclude packages and classes. A more 
convenient suggestion would be to have jmod accept a file such as 
jdk/make/modules/modules.config [3] which is the definitive file used by 
the JDK modules build to determine which classes go in which module.

However we choose to update jmod, or a <jmod> task, it would be really 
helpful if we could compile classes in whatever way we consider usual, 
then be able to use jmod to create an incremental library containing 
just the modules that are currently being developed.

-- Jon


1. http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000719.html

2. Speaking of Ant tasks, it would be good to have one for jmod, 
especially one that recognizes that modules are up to date and do not 
need to be recreated.

3. 
http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/modules/modules.config


From jonathan.gibbons at oracle.com  Sat Apr  3 14:45:36 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 03 Apr 2010 14:45:36 -0700
Subject: -L switch
Message-ID: <4BB7B700.4050409@oracle.com>

Various JDK tools are now beginning to accept a "-L library" option. 
(java, jmod, javac etc)

It would help if the java command's "-L library" had a variant that did 
not involve whitespace. The reasons are the same as for the java 
command's "-bootclasspath path" and "-Xbootclasspath:path" options. If 
you have a tool that is invoked by the launcher, it is helpful to be 
able to tunnel options to the JVM using the -J convention.     e.g.    
javac -J-Xbootclasspath:my-path.

With the current spec of the -L option, we will have to cross our 
fingers and hope that it works to prefix both the option and the 
argument with -J, as in
      javac -J-L -Jmy-library

I have two suggestions on how we can achieve this:

1.    Allow "-L:my-library" as well as "-L library"
2.    By analogy with -bootclasspath, provide "-XL:path"

-- Jon


From mandy.chung at oracle.com  Sat Apr  3 16:13:37 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 03 Apr 2010 16:13:37 -0700
Subject: jigsaw builds
In-Reply-To: <4BB7AD0C.9030009@oracle.com>
References: <4BB7AD0C.9030009@oracle.com>
Message-ID: <4BB7CBA1.6060302@oracle.com>

Jonathan Gibbons wrote:
> The jigsaw modules builds do not include src.zip and the demo and 
> sample directories.
>
> Is this intentional, accidental, or just "not got around to it, yet?"
It's on the TODO list, line 57-73:
   
http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/common/Modules.gmk

We may want to modularize the src.zip and demo/samples that need further 
discussion.

Thanks
Mandy
>
>> $ ls build/linux-amd64/j2sdk-image/
>> ASSEMBLY_EXCEPTION  bin  demo  include  jre  lib  LICENSE  man  
>> sample  src.zip  THIRD_PARTY_README
>> $ ls build/linux-amd64/jdk-module-image/
>> ASSEMBLY_EXCEPTION  bin  include  lib  LICENSE  THIRD_PARTY_README
>
> -- Jon



From jonathan.gibbons at oracle.com  Sat Apr  3 17:07:34 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 03 Apr 2010 17:07:34 -0700
Subject: sun.boot.class.path
Message-ID: <4BB7D846.8020406@oracle.com>

Jigsaw runtime folk,

Currently, javac relies on the Java runtime setting the system property 
sun.boot.class.path being set to the bootclasspath for the underlying 
JVM being used to run javac. This system property is used to locate 
platform classes when the javac -Xbootclasspath option has not been given.

Going forward, can I rely on this property always being set, in both 
legacy mode and module mode for a JVM?

The issue for javac is to how to handle compilations for older values of 
-source.

The options are:
1. rely on sun.boot.class.path being available if the javac 
-Xbootclasspath option is not set.

2. Give an error for older values of -source if -Xbootclasspath is not 
set.  Setting -Xbootclasspath is good practice anyway, and Joe Darcy has 
already advocated making this a warning.

3. Adapt the javac internals so that if javac -Xbootclasspath is not 
set, javac will use the Jigsaw default platform module, assuming Jigsaw 
is available and installed. (Eventually, this will normally always be 
the case.)

-- Jon




From jonathan.gibbons at oracle.com  Sat Apr  3 17:30:07 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 03 Apr 2010 17:30:07 -0700
Subject: jigsaw builds
In-Reply-To: <4BB7CBA1.6060302@oracle.com>
References: <4BB7AD0C.9030009@oracle.com> <4BB7CBA1.6060302@oracle.com>
Message-ID: <4BB7DD8F.3000103@oracle.com>

Mandy Chung wrote:
> Jonathan Gibbons wrote:
>> The jigsaw modules builds do not include src.zip and the demo and 
>> sample directories.
>>
>> Is this intentional, accidental, or just "not got around to it, yet?"
> It's on the TODO list, line 57-73:
>   
> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/common/Modules.gmk 
>
>
> We may want to modularize the src.zip and demo/samples that need 
> further discussion.

Eeek. Modularizing src.zip sounds like a real PITA, although I can see 
why it might be considered. It seems to me we're on the edge of a 
discussion about whether it really is worth it to use modules to 
organize large source code for a lot of fine grained modules, or whether 
modules are just a packaging time issue.

-- Jon

>
> Thanks
> Mandy
>>
>>> $ ls build/linux-amd64/j2sdk-image/
>>> ASSEMBLY_EXCEPTION  bin  demo  include  jre  lib  LICENSE  man  
>>> sample  src.zip  THIRD_PARTY_README
>>> $ ls build/linux-amd64/jdk-module-image/
>>> ASSEMBLY_EXCEPTION  bin  include  lib  LICENSE  THIRD_PARTY_README
>>
>> -- Jon
>



From karen.kinnear at oracle.com  Sat Apr  3 08:42:26 2010
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Sat, 3 Apr 2010 11:42:26 -0400
Subject: Module access question
In-Reply-To: <4BB66E83.8040208@oracle.com>
References: <FDCD96C7-8AE9-4DF4-9592-A4A5255E3160@sun.com>
	<4BB66E83.8040208@oracle.com>
Message-ID: <6320FEDE-0AB4-4625-A1F6-B6058F656D87@oracle.com>

Riaz,

Also note that access control for module-private is not coming in the  
OJ timeframe.

thanks,
Karen

On Apr 2, 2010, at 6:24 PM, Alex Buckley wrote:

> Yes, just make the types in foo.impl be module-private via the  
> "module" keyword. They can extend/implement the public types in  
> foo.api, but will be inaccessible to types outside the foo module.  
> Of course there will probably be some public factory or other entry  
> point in foo.impl to get things going.
>
> Note that the "module" accessibility level is a feature of JSR 294,  
> but which types are in which module is a property of the module  
> system you are using. In the RI of JSR 294, javac determines which  
> types are in the "foo" module versus in other modules based on the  
> modulepath.
>
> Alex
>
> On 4/2/2010 3:16 PM, Riaz A Aimandi wrote:
>> Hi,
>> I have a quick question regarding modules.
>> Lets say I have a module that has both API & Implementation (in  
>> different packages)
>> Is it possible to restrict access from other modules to API only  
>> (both at compile & runtime) ?
>> i.e., disallow implementation classes to be directly accessed from  
>> other modules.
>> Example:
>>    Module foo:
>>    package foo.api.* : has API
>>    package foo.impl.* has Implementation
>>    I want to restrict direct access to foo.impl.* from any module  
>> that requires this module.
>> I understand that with multiple modules this could be easily done.  
>> But I am hoping that I do not have to breakup modules just for this  
>> purpose.
>> Thanks,
>> - riaz



From Roger.Riggs at Oracle.com  Sun Apr  4 18:26:46 2010
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sun, 04 Apr 2010 21:26:46 -0400
Subject: jmod comments
In-Reply-To: <4BB7B46D.3040202@oracle.com>
References: <4BB7B46D.3040202@oracle.com>
Message-ID: <4BB93C56.5090109@Oracle.com>

Hi Jon,

I would think it would be most useful of Javac could be given a module 
definition
including lists of classes, etc. and directly compile the classes and 
insert them
into the Library.  JavaC already knows the structure and semantics of 
modules
and so it should not be a stretch to see that it could directly generate 
into the library.
Since it would be given version information it can correctly create a 
new module
or update the contents of an existing module.  Regardless of the update 
mechanism
the snapshot of bindings between classes and modules would need to be 
re-evaluated.

And it would address the incremental compilation problem as well if 
javac compiles
only the classes that have changed.

btw, assuming that the module boundaries make sense and are sustainable 
then
it would think that it would beneficial to rearrange the OpenJDK source 
structure
to match the module structure at some point so maybe the current awkwardness
is a growing pain and short lived.

$.02, Roger




Jonathan Gibbons wrote:
> There is currently a mismatch between the way that we think the Jigsaw 
> tools should be used and the way we actually use them in practice.
>
> In particular, jmod does not well serve the needs of the primary 
> Jigsaw client, the JDK itself.
>
> jmod currently assumes that the classes are laid out neatly on disk in 
> separate hierarchies for each module. That's very convenient, if that 
> is actually how your classes are organized, but I venture to suggest 
> that with the current fine grain module scheme, the JDK classes are 
> never ever going to be laid out that way. So currently, the JDK build 
> jumps through hoops moving classes around after they have been built, 
> in order to satisfy the jmod input requirements. The tail is 
> definitely wagging the dog here.
>
> I'm also coming at this from a similar but different perspective: 
> langtools, and the as-yet-unresolved issue of -Xbootclasspath and 
> incremental builds. [1]
>
> In langtools, we currently use -J-Xbootclasspath to avoid having to 
> recompile JDK every time we edit javac or other langtools tools. In a 
> Jigsaw world, the replacement would seem to be to build and use a 
> private module library which has a standard JDK module library as its 
> parent.  Thus, -J-Xbootclasspath gets replaced by -J-L. But that just 
> defers the issue one step -- I still have to build the library, with 
> jmod, meaning all the classes have to be moved around into 
> module-specific hierarchies, and that just seems wrong.
>
> It would be much better if there was a way that jmod could be given 
> information about what classes belong in each module. If this was an 
> Ant task[2], I would expect to see something like filesets being used 
> to describe the contents of each module. In the absence of an Ant 
> task, one suggestion would be to provide -include and -exclude options 
> on the command line to include and exclude packages and classes. A 
> more convenient suggestion would be to have jmod accept a file such as 
> jdk/make/modules/modules.config [3] which is the definitive file used 
> by the JDK modules build to determine which classes go in which module.
>
> However we choose to update jmod, or a <jmod> task, it would be really 
> helpful if we could compile classes in whatever way we consider usual, 
> then be able to use jmod to create an incremental library containing 
> just the modules that are currently being developed.
>
> -- Jon
>
>
> 1. 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000719.html
>
> 2. Speaking of Ant tasks, it would be good to have one for jmod, 
> especially one that recognizes that modules are up to date and do not 
> need to be recreated.
>
> 3. 
> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/modules/modules.config 
>



From jonathan.gibbons at oracle.com  Sun Apr  4 21:44:47 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 04 Apr 2010 21:44:47 -0700
Subject: jmod comments
In-Reply-To: <4BB93C56.5090109@Oracle.com>
References: <4BB7B46D.3040202@oracle.com> <4BB93C56.5090109@Oracle.com>
Message-ID: <4BB96ABF.3010508@oracle.com>

Roger,

Thank you for your $0.02.

It is not clear that it is an easier or better to compile into a module 
than it is to compile into a jar file, and that is something that 
traditionally, javac has not done. javac has enough options now, and I'm 
not sure how well we could graft on the additional extra options for 
creating and updating module libraries.  That all being said, this is 
something that others could experiment with, because the sort of 
features you describe could likely be provided by a suitable 
JavaFileManager, capable of writing into a module library, and exercised 
through the JSR 199 API.

I know Ant does not meet with universal acclaim, but I think the idea of 
having tools using a single JVM able to invoke javac and then invoke 
module tools like jmod is a good one. I think that gives a useful 
flexibility (modularity?).   That all being said, if there are 
reasonable opportunities to make easy cases easier, I am open to 
suggestions.

As for module boundaries, the module boundaries being proposed for JDK 
are very fine grain [*], and I do not think they are amenable to a 
restructuring of the source tree -- especially when classes in the same 
package are separated into different modules. I think for newer code, it 
will be easier to have the source structure mirror the module structure, 
but for large legacy code bases that are being retroactively broken into 
fine grain modules, I am not so sure the same will apply.

[*] In langtools, the proposed structure seemed to be one module for the 
main set of classes, with additional modules for each tools main class, 
with some other classes being pulled out and treated specially.  I 
forget where public API like javax.tools and javax.lang.model ended up.  
Mandy may have changed the assignment since I looked in detail.   For 
langtools, it has also traditionally been the case that langtools/ repo 
provides its classes, but the jdk/ build determines the packaging, 
deciding which classes go in rt.jar and tools.jar.  OK, rt.jar and 
tools.jar are going away, but the structure of the build is still such 
that module packaging is determined in the jdk/ repo build.

-- Jon


Roger Riggs wrote:
> Hi Jon,
>
> I would think it would be most useful of Javac could be given a module 
> definition
> including lists of classes, etc. and directly compile the classes and 
> insert them
> into the Library.  JavaC already knows the structure and semantics of 
> modules
> and so it should not be a stretch to see that it could directly 
> generate into the library.
> Since it would be given version information it can correctly create a 
> new module
> or update the contents of an existing module.  Regardless of the 
> update mechanism
> the snapshot of bindings between classes and modules would need to be 
> re-evaluated.
>
> And it would address the incremental compilation problem as well if 
> javac compiles
> only the classes that have changed.
>
> btw, assuming that the module boundaries make sense and are 
> sustainable then
> it would think that it would beneficial to rearrange the OpenJDK 
> source structure
> to match the module structure at some point so maybe the current 
> awkwardness
> is a growing pain and short lived.
>
> $.02, Roger
>
>
>
>
> Jonathan Gibbons wrote:
>> There is currently a mismatch between the way that we think the 
>> Jigsaw tools should be used and the way we actually use them in 
>> practice.
>>
>> In particular, jmod does not well serve the needs of the primary 
>> Jigsaw client, the JDK itself.
>>
>> jmod currently assumes that the classes are laid out neatly on disk 
>> in separate hierarchies for each module. That's very convenient, if 
>> that is actually how your classes are organized, but I venture to 
>> suggest that with the current fine grain module scheme, the JDK 
>> classes are never ever going to be laid out that way. So currently, 
>> the JDK build jumps through hoops moving classes around after they 
>> have been built, in order to satisfy the jmod input requirements. The 
>> tail is definitely wagging the dog here.
>>
>> I'm also coming at this from a similar but different perspective: 
>> langtools, and the as-yet-unresolved issue of -Xbootclasspath and 
>> incremental builds. [1]
>>
>> In langtools, we currently use -J-Xbootclasspath to avoid having to 
>> recompile JDK every time we edit javac or other langtools tools. In a 
>> Jigsaw world, the replacement would seem to be to build and use a 
>> private module library which has a standard JDK module library as its 
>> parent.  Thus, -J-Xbootclasspath gets replaced by -J-L. But that just 
>> defers the issue one step -- I still have to build the library, with 
>> jmod, meaning all the classes have to be moved around into 
>> module-specific hierarchies, and that just seems wrong.
>>
>> It would be much better if there was a way that jmod could be given 
>> information about what classes belong in each module. If this was an 
>> Ant task[2], I would expect to see something like filesets being used 
>> to describe the contents of each module. In the absence of an Ant 
>> task, one suggestion would be to provide -include and -exclude 
>> options on the command line to include and exclude packages and 
>> classes. A more convenient suggestion would be to have jmod accept a 
>> file such as jdk/make/modules/modules.config [3] which is the 
>> definitive file used by the JDK modules build to determine which 
>> classes go in which module.
>>
>> However we choose to update jmod, or a <jmod> task, it would be 
>> really helpful if we could compile classes in whatever way we 
>> consider usual, then be able to use jmod to create an incremental 
>> library containing just the modules that are currently being developed.
>>
>> -- Jon
>>
>>
>> 1. 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000719.html
>>
>> 2. Speaking of Ant tasks, it would be good to have one for jmod, 
>> especially one that recognizes that modules are up to date and do not 
>> need to be recreated.
>>
>> 3. 
>> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/modules/modules.config 
>>
>



From jonathan.gibbons at oracle.com  Sun Apr  4 21:57:11 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 04 Apr 2010 21:57:11 -0700
Subject: javac modes
Message-ID: <4BB96DA7.6010102@oracle.com>

In the new world of JDK 7, modules, and Jigsaw, we are beginning to see 
to more talk of "modes", such as the ability of the JVM to run code in 
"legacy mode" or "module mode".  javac has some additional kinds of 
modes, which are all somewhat independent of each other, and which 
should not be confused.  This note attempts to describe the different 
kinds of modes supported by javac.


1. JVM execution mode

This refers to the way in which javac is run by the underlying JVM.

1.a) module mode

In module mode, the javac launcher invokes the javac module directly.

1.b) legacy mode

In legacy mode, the javac launcher invokes javac using a main class and 
a class path.

1.c) bootstrap mode

In bootstrap mode, javac is executed by putting the classes for javac on 
the JVM bootclasspath of an earlier version of javac. (javac 
-J-Xbootclasspath/p:javac.jar ...)  The javac classes must have been 
compiled for use with that earlier version. This mode is always used to 
compile the rest of the JDK classes.


The default JVM execution mode for javac is a property of how the javac 
launcher is created. Module mode and legacy mode can be selected by 
using the JVM's -Xmode option, which can be escaped through the javac 
command line using -J in the normal manner. (i.e.  javac -J-Xmode:legacy 
...)

In module mode, the javac launcher will use the default system module 
library to locate the javac module. See the mail thread [1] for a 
discussion of using the JVM -L option to change the module library used 
to locate the javac module and the modules it depends on.

For the most part, javac's functionality is independent of the JVM 
execution mode used to start javac. However, some of javac's other modes 
rely on a system property "sun.boot.class.path" being set by the JVM 
runtime to a path for the standard runtime classes, such as found in 
rt.jar or its equivalent. See mail thread [2] for more discussion on 
sun.boot.class.path.


2. Module resolution mode

This refers to the way in which javac locates classes and resolves 
module dependencies. Some of the modes here are just for bootstrapping 
and testing purposes.

2.a) Jigsaw mode

This is the primary, default, module resolution mode. It requires that 
javac has access to the org.openjdk.jigsaw API, and that a module 
library is available, meaning that either a library has been specified 
with the -L option, or javac has been run in the module JVM execution 
mode (1.a, above.)

2.b) 294 RI mode

This has been newly identified, and is not yet supported. It will likely 
be akin to a subset of Jigsaw mode, in which module properties are 
inferred from the compilation environment without the use of 
module-info.java.

2.c) ZeroMod mode

ZeroMod refers to a primitive module resolver built directly into javac. 
It is primarily intended for bootstrapping (i.e. building JDK without 
the benefit of Jigsaw itself) and for testing those aspects of javac 
functionality which do not directly depend on Jigsaw functionality. It 
is used if javac is executed in bootstrap or legacy mode: i.e. if the 
Jigsaw API is not available or if no module library is available.  This 
mode can also be forced by the use of the hidden javac option 
-XDzeroMod. The ZeroMod module resolver provides only very minimal 
support for version queries and version selection.

2.d) No modules mode

Modules are not supported in this mode. Classes are located in the same 
way as for earlier versions of javac. It can be thought of as "javac's 
legacy mode". This mode can be selected with the hidden javac option 
-XDnomodules, although it is intended that this is for debugging and 
testing purposes only. javac provides equivalent legacy command line 
functionality using "single-module" mode (3.a) and any of the other 
module resolution modes (2.a, 2.b, 2.c) although the internal code paths 
within javac will be different in these cases.


3. Module compilation mode

This refers to whether javac is compiling classes for multiple modules 
at the same time, or not.

3.a) Single module mode

This is used to compile non-modular code or for code in a single module. 
This is the mode that will be automatically used for any javac command 
line that was valid for earlier versions of javac. In this mode, the -d, 
-classpath and -sourcepath options all have the same usage as before.

3.b) Multi-module mode

This is used to compile source code for multiple modules in the the same 
compilation. It is used if the new option "-modulepath" is used instead 
of "-classpath".  In this mode, the -d and -sourcepath options both use 
an extra level of directory naming above the standard package directory 
hierarchy.


In both modes, a module or modules found on the command line (either 
explicitly or on one of the available path options) will be taken into 
account by the module resolver, which will look for any unresolved 
dependencies in the system module library, or a library specified by the 
-L option. Note that this means that in Jigsaw mode (2.a) javac will 
create and use a "temporary library" in memory to handle the modules 
found in the compilation environment.


---------------------

[1] -L:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html

[2] sun.boot.class.path
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000758.html


From forax at univ-mlv.fr  Mon Apr  5 06:27:33 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 05 Apr 2010 15:27:33 +0200
Subject: jigsaw builds
In-Reply-To: <4BB7DD8F.3000103@oracle.com>
References: <4BB7AD0C.9030009@oracle.com> <4BB7CBA1.6060302@oracle.com>
	<4BB7DD8F.3000103@oracle.com>
Message-ID: <4BB9E545.1010702@univ-mlv.fr>

Le 04/04/2010 02:30, Jonathan Gibbons a ?crit :
> Mandy Chung wrote:
>> Jonathan Gibbons wrote:
>>> The jigsaw modules builds do not include src.zip and the demo and 
>>> sample directories.
>>>
>>> Is this intentional, accidental, or just "not got around to it, yet?"
>> It's on the TODO list, line 57-73:
>>   
>> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/57a86394f749/make/common/Modules.gmk 
>>
>>
>> We may want to modularize the src.zip and demo/samples that need 
>> further discussion.
>
> Eeek. Modularizing src.zip sounds like a real PITA, although I can see 
> why it might be considered. It seems to me we're on the edge of a 
> discussion about whether it really is worth it to use modules to 
> organize large source code for a lot of fine grained modules, or 
> whether modules are just a packaging time issue.

Jon, modularizing src.zip is not a problem if javac does the job.

>
> -- Jon

R?mi

>
>>
>> Thanks
>> Mandy
>>>
>>>> $ ls build/linux-amd64/j2sdk-image/
>>>> ASSEMBLY_EXCEPTION  bin  demo  include  jre  lib  LICENSE  man  
>>>> sample  src.zip  THIRD_PARTY_README
>>>> $ ls build/linux-amd64/jdk-module-image/
>>>> ASSEMBLY_EXCEPTION  bin  include  lib  LICENSE  THIRD_PARTY_README
>>>
>>> -- Jon
>>
>



From mr at sun.com  Mon Apr  5 08:39:48 2010
From: mr at sun.com (mr at sun.com)
Date: Mon, 05 Apr 2010 15:39:48 +0000
Subject: hg: jigsaw/jigsaw/jdk: Reduce test verbosity
Message-ID: <20100405154124.7D6E5442C5@hg.openjdk.java.net>

Changeset: ef005298cf02
Author:    mr
Date:      2010-04-05 08:37 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ef005298cf02

Reduce test verbosity

! test/org/openjdk/jigsaw/_Library.java
! test/org/openjdk/jigsaw/library.sh
! test/org/openjdk/jigsaw/preinstall.sh



From mandy.chung at oracle.com  Mon Apr  5 10:02:56 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 10:02:56 -0700
Subject: sun.boot.class.path
In-Reply-To: <4BB7D846.8020406@oracle.com>
References: <4BB7D846.8020406@oracle.com>
Message-ID: <4BBA17C0.6050105@oracle.com>

Jonathan Gibbons wrote:
> Jigsaw runtime folk,
>
> Currently, javac relies on the Java runtime setting the system 
> property sun.boot.class.path being set to the bootclasspath for the 
> underlying JVM being used to run javac. This system property is used 
> to locate platform classes when the javac -Xbootclasspath option has 
> not been given.
>
> Going forward, can I rely on this property always being set, in both 
> legacy mode and module mode for a JVM?
>

In the modular jdk, bootclasspath would eventually go away.  You can't 
reply on the sun.boot.class.path property value to locate the platform 
classes.
> The issue for javac is to how to handle compilations for older values 
> of -source.
>
> The options are:
> 1. rely on sun.boot.class.path being available if the javac 
> -Xbootclasspath option is not set.
>
> 2. Give an error for older values of -source if -Xbootclasspath is not 
> set.  Setting -Xbootclasspath is good practice anyway, and Joe Darcy 
> has already advocated making this a warning.
>
> 3. Adapt the javac internals so that if javac -Xbootclasspath is not 
> set, javac will use the Jigsaw default platform module, assuming 
> Jigsaw is available and installed. (Eventually, this will normally 
> always be the case.)
IMO, option #3 is the right solution and issuing a warning if 
-Xbootclasspath is not set for older values of -source seems good to me.

There is an open issue which platform module javac should use to find 
platform classes.   Such platform module should find all platform 
classes that are installed in the system module library of one or more 
platform modules.

The minimal module image is "jdk.base" that contains a subset of the 
JRE.   Currently, the jigsaw default platform module is "jdk at 7-ea" that 
is intended to represent the full JRE (the name of this module should 
probably be "jre").  The default platform module requires all JRE 
modules be installed.  If javac runs on the minimal module image (i.e. 
jdk-base-image), it will fail to find the default platform module 
"jdk at 7-ea".   I'm looking into a solution for this.  For "javac's legacy 
mode", probably javac needs to use "jdk.legacy" module that optionally 
depends on all JRE modules so that the "jdk.legacy" module can be 
installed in the minimal module image while it can find classes from 
other platform modules later installed on a system module library.  I'll 
send out the details of this idea for discussion.

Mandy



From mandy.chung at oracle.com  Mon Apr  5 10:49:55 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 10:49:55 -0700
Subject: javac modes
In-Reply-To: <4BB96DA7.6010102@oracle.com>
References: <4BB96DA7.6010102@oracle.com>
Message-ID: <4BBA22C3.8090605@oracle.com>

Jon,

Thanks for writing this up.  This is very helpful and we can use the 
same terminology thereafter.

One question related to (2.a) Jigsaw mode:  what happens when javac runs 
in the legacy JVM execution mode (1.b) from a jdk-module-image (i.e. 
javac can access to the org.openjdk.jigsaw API  and the system module 
library is available)?

Mandy

Jonathan Gibbons wrote:
> In the new world of JDK 7, modules, and Jigsaw, we are beginning to 
> see to more talk of "modes", such as the ability of the JVM to run 
> code in "legacy mode" or "module mode".  javac has some additional 
> kinds of modes, which are all somewhat independent of each other, and 
> which should not be confused.  This note attempts to describe the 
> different kinds of modes supported by javac.
>
>
> 1. JVM execution mode
>
> This refers to the way in which javac is run by the underlying JVM.
>
> 1.a) module mode
>
> In module mode, the javac launcher invokes the javac module directly.
>
> 1.b) legacy mode
>
> In legacy mode, the javac launcher invokes javac using a main class 
> and a class path.
>
> 1.c) bootstrap mode
>
> In bootstrap mode, javac is executed by putting the classes for javac 
> on the JVM bootclasspath of an earlier version of javac. (javac 
> -J-Xbootclasspath/p:javac.jar ...)  The javac classes must have been 
> compiled for use with that earlier version. This mode is always used 
> to compile the rest of the JDK classes.
>
>
> The default JVM execution mode for javac is a property of how the 
> javac launcher is created. Module mode and legacy mode can be selected 
> by using the JVM's -Xmode option, which can be escaped through the 
> javac command line using -J in the normal manner. (i.e.  javac 
> -J-Xmode:legacy ...)
>
> In module mode, the javac launcher will use the default system module 
> library to locate the javac module. See the mail thread [1] for a 
> discussion of using the JVM -L option to change the module library 
> used to locate the javac module and the modules it depends on.
>
> For the most part, javac's functionality is independent of the JVM 
> execution mode used to start javac. However, some of javac's other 
> modes rely on a system property "sun.boot.class.path" being set by the 
> JVM runtime to a path for the standard runtime classes, such as found 
> in rt.jar or its equivalent. See mail thread [2] for more discussion 
> on sun.boot.class.path.
>
>
> 2. Module resolution mode
>
> This refers to the way in which javac locates classes and resolves 
> module dependencies. Some of the modes here are just for bootstrapping 
> and testing purposes.
>
> 2.a) Jigsaw mode
>
> This is the primary, default, module resolution mode. It requires that 
> javac has access to the org.openjdk.jigsaw API, and that a module 
> library is available, meaning that either a library has been specified 
> with the -L option, or javac has been run in the module JVM execution 
> mode (1.a, above.)
>
> 2.b) 294 RI mode
>
> This has been newly identified, and is not yet supported. It will 
> likely be akin to a subset of Jigsaw mode, in which module properties 
> are inferred from the compilation environment without the use of 
> module-info.java.
>
> 2.c) ZeroMod mode
>
> ZeroMod refers to a primitive module resolver built directly into 
> javac. It is primarily intended for bootstrapping (i.e. building JDK 
> without the benefit of Jigsaw itself) and for testing those aspects of 
> javac functionality which do not directly depend on Jigsaw 
> functionality. It is used if javac is executed in bootstrap or legacy 
> mode: i.e. if the Jigsaw API is not available or if no module library 
> is available.  This mode can also be forced by the use of the hidden 
> javac option -XDzeroMod. The ZeroMod module resolver provides only 
> very minimal support for version queries and version selection.
>
> 2.d) No modules mode
>
> Modules are not supported in this mode. Classes are located in the 
> same way as for earlier versions of javac. It can be thought of as 
> "javac's legacy mode". This mode can be selected with the hidden javac 
> option -XDnomodules, although it is intended that this is for 
> debugging and testing purposes only. javac provides equivalent legacy 
> command line functionality using "single-module" mode (3.a) and any of 
> the other module resolution modes (2.a, 2.b, 2.c) although the 
> internal code paths within javac will be different in these cases.
>
>
> 3. Module compilation mode
>
> This refers to whether javac is compiling classes for multiple modules 
> at the same time, or not.
>
> 3.a) Single module mode
>
> This is used to compile non-modular code or for code in a single 
> module. This is the mode that will be automatically used for any javac 
> command line that was valid for earlier versions of javac. In this 
> mode, the -d, -classpath and -sourcepath options all have the same 
> usage as before.
>
> 3.b) Multi-module mode
>
> This is used to compile source code for multiple modules in the the 
> same compilation. It is used if the new option "-modulepath" is used 
> instead of "-classpath".  In this mode, the -d and -sourcepath options 
> both use an extra level of directory naming above the standard package 
> directory hierarchy.
>
>
> In both modes, a module or modules found on the command line (either 
> explicitly or on one of the available path options) will be taken into 
> account by the module resolver, which will look for any unresolved 
> dependencies in the system module library, or a library specified by 
> the -L option. Note that this means that in Jigsaw mode (2.a) javac 
> will create and use a "temporary library" in memory to handle the 
> modules found in the compilation environment.
>
>
> ---------------------
>
> [1] -L:
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html
>
> [2] sun.boot.class.path
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000758.html



From jonathan.gibbons at oracle.com  Mon Apr  5 11:04:37 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 11:04:37 -0700
Subject: javac modes
In-Reply-To: <4BBA22C3.8090605@oracle.com>
References: <4BB96DA7.6010102@oracle.com> <4BBA22C3.8090605@oracle.com>
Message-ID: <4BBA2635.5050008@oracle.com>

Mandy,

The only connection between "JVM execution mode" (1.*) and "module 
resolution mode" (2.*) is the issues related to the sun.boot.class.path 
property. In situations where sun.boot.class.path does not come into 
play, JVM execution mode and module resolution mode are completely 
independent.  Thus, Jigsaw module resolution mode (2.a) should work just 
fine in legacy JVM execution mode (1.b). 

I'll have another note perhaps later today on practical ways to run 
javac and the javac regression tests in different combinations of these 
modes.

-- Jon



Mandy Chung wrote:
> Jon,
>
> Thanks for writing this up.  This is very helpful and we can use the 
> same terminology thereafter.
>
> One question related to (2.a) Jigsaw mode:  what happens when javac 
> runs in the legacy JVM execution mode (1.b) from a jdk-module-image 
> (i.e. javac can access to the org.openjdk.jigsaw API  and the system 
> module library is available)?
>
> Mandy
>
> Jonathan Gibbons wrote:
>> In the new world of JDK 7, modules, and Jigsaw, we are beginning to 
>> see to more talk of "modes", such as the ability of the JVM to run 
>> code in "legacy mode" or "module mode".  javac has some additional 
>> kinds of modes, which are all somewhat independent of each other, and 
>> which should not be confused.  This note attempts to describe the 
>> different kinds of modes supported by javac.
>>
>>
>> 1. JVM execution mode
>>
>> This refers to the way in which javac is run by the underlying JVM.
>>
>> 1.a) module mode
>>
>> In module mode, the javac launcher invokes the javac module directly.
>>
>> 1.b) legacy mode
>>
>> In legacy mode, the javac launcher invokes javac using a main class 
>> and a class path.
>>
>> 1.c) bootstrap mode
>>
>> In bootstrap mode, javac is executed by putting the classes for javac 
>> on the JVM bootclasspath of an earlier version of javac. (javac 
>> -J-Xbootclasspath/p:javac.jar ...)  The javac classes must have been 
>> compiled for use with that earlier version. This mode is always used 
>> to compile the rest of the JDK classes.
>>
>>
>> The default JVM execution mode for javac is a property of how the 
>> javac launcher is created. Module mode and legacy mode can be 
>> selected by using the JVM's -Xmode option, which can be escaped 
>> through the javac command line using -J in the normal manner. (i.e.  
>> javac -J-Xmode:legacy ...)
>>
>> In module mode, the javac launcher will use the default system module 
>> library to locate the javac module. See the mail thread [1] for a 
>> discussion of using the JVM -L option to change the module library 
>> used to locate the javac module and the modules it depends on.
>>
>> For the most part, javac's functionality is independent of the JVM 
>> execution mode used to start javac. However, some of javac's other 
>> modes rely on a system property "sun.boot.class.path" being set by 
>> the JVM runtime to a path for the standard runtime classes, such as 
>> found in rt.jar or its equivalent. See mail thread [2] for more 
>> discussion on sun.boot.class.path.
>>
>>
>> 2. Module resolution mode
>>
>> This refers to the way in which javac locates classes and resolves 
>> module dependencies. Some of the modes here are just for 
>> bootstrapping and testing purposes.
>>
>> 2.a) Jigsaw mode
>>
>> This is the primary, default, module resolution mode. It requires 
>> that javac has access to the org.openjdk.jigsaw API, and that a 
>> module library is available, meaning that either a library has been 
>> specified with the -L option, or javac has been run in the module JVM 
>> execution mode (1.a, above.)
>>
>> 2.b) 294 RI mode
>>
>> This has been newly identified, and is not yet supported. It will 
>> likely be akin to a subset of Jigsaw mode, in which module properties 
>> are inferred from the compilation environment without the use of 
>> module-info.java.
>>
>> 2.c) ZeroMod mode
>>
>> ZeroMod refers to a primitive module resolver built directly into 
>> javac. It is primarily intended for bootstrapping (i.e. building JDK 
>> without the benefit of Jigsaw itself) and for testing those aspects 
>> of javac functionality which do not directly depend on Jigsaw 
>> functionality. It is used if javac is executed in bootstrap or legacy 
>> mode: i.e. if the Jigsaw API is not available or if no module library 
>> is available.  This mode can also be forced by the use of the hidden 
>> javac option -XDzeroMod. The ZeroMod module resolver provides only 
>> very minimal support for version queries and version selection.
>>
>> 2.d) No modules mode
>>
>> Modules are not supported in this mode. Classes are located in the 
>> same way as for earlier versions of javac. It can be thought of as 
>> "javac's legacy mode". This mode can be selected with the hidden 
>> javac option -XDnomodules, although it is intended that this is for 
>> debugging and testing purposes only. javac provides equivalent legacy 
>> command line functionality using "single-module" mode (3.a) and any 
>> of the other module resolution modes (2.a, 2.b, 2.c) although the 
>> internal code paths within javac will be different in these cases.
>>
>>
>> 3. Module compilation mode
>>
>> This refers to whether javac is compiling classes for multiple 
>> modules at the same time, or not.
>>
>> 3.a) Single module mode
>>
>> This is used to compile non-modular code or for code in a single 
>> module. This is the mode that will be automatically used for any 
>> javac command line that was valid for earlier versions of javac. In 
>> this mode, the -d, -classpath and -sourcepath options all have the 
>> same usage as before.
>>
>> 3.b) Multi-module mode
>>
>> This is used to compile source code for multiple modules in the the 
>> same compilation. It is used if the new option "-modulepath" is used 
>> instead of "-classpath".  In this mode, the -d and -sourcepath 
>> options both use an extra level of directory naming above the 
>> standard package directory hierarchy.
>>
>>
>> In both modes, a module or modules found on the command line (either 
>> explicitly or on one of the available path options) will be taken 
>> into account by the module resolver, which will look for any 
>> unresolved dependencies in the system module library, or a library 
>> specified by the -L option. Note that this means that in Jigsaw mode 
>> (2.a) javac will create and use a "temporary library" in memory to 
>> handle the modules found in the compilation environment.
>>
>>
>> ---------------------
>>
>> [1] -L:
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html
>>
>> [2] sun.boot.class.path
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000758.html
>



From mandy.chung at oracle.com  Mon Apr  5 14:01:54 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 14:01:54 -0700
Subject: Please rview simple clean up of the modules build for javac
Message-ID: <4BBA4FC2.2060009@oracle.com>

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




From jonathan.gibbons at oracle.com  Mon Apr  5 14:40:09 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 14:40:09 -0700
Subject: Please rview simple clean up of the modules build for javac
In-Reply-To: <4BBA4FC2.2060009@oracle.com>
References: <4BBA4FC2.2060009@oracle.com>
Message-ID: <4BBA58B9.80003@oracle.com>

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

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.

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.

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.

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?

-- 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
>
>



From alex.buckley at oracle.com  Mon Apr  5 14:43:35 2010
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 05 Apr 2010 14:43:35 -0700
Subject: javac modes
In-Reply-To: <4BB96DA7.6010102@oracle.com>
References: <4BB96DA7.6010102@oracle.com>
Message-ID: <4BBA5987.7050005@oracle.com>

On 4/4/2010 9:57 PM, Jonathan Gibbons wrote:
> 2. Module resolution mode
> 
> This refers to the way in which javac locates classes and resolves 
> module dependencies. 

Do you mean: "in which javac locates classes *of modules other than the 
module for the compilation unit being compiled* and resolves module 
dependencies *of the module for the compilation unit being compiled*" ?

I ask because I'm trying to work out where module-info.java fits in. Oh 
wait, here it is:

> In both modes, a module or modules found on the command line (either 
> explicitly or on one of the available path options) will be taken into 
> account by the module resolver, which will look for any unresolved 
> dependencies in the system module library, or a library specified by the 
> -L option.

So you can supply one module-info.java file (3a) or multiple 
module-info.java files (3b) on the command line, whether resolution is 
done with Jigsaw (2a) or ZeroMod (2c).

If you supply zero module-info.java files on the command line, in which 
modes will module-info.class be read silently to obtain dependencies for 
normal compilation units supplied on the command line?

Alex


From mandy.chung at oracle.com  Mon Apr  5 15:04:05 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 15:04:05 -0700
Subject: Please rview simple clean up of the modules build for javac
In-Reply-To: <4BBA58B9.80003@oracle.com>
References: <4BBA4FC2.2060009@oracle.com> <4BBA58B9.80003@oracle.com>
Message-ID: <4BBA5E55.4080803@oracle.com>

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
>>
>>
>



From jonathan.gibbons at oracle.com  Mon Apr  5 15:10:53 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 15:10:53 -0700
Subject: javac modes
In-Reply-To: <4BBA5987.7050005@oracle.com>
References: <4BB96DA7.6010102@oracle.com> <4BBA5987.7050005@oracle.com>
Message-ID: <4BBA5FED.3060502@oracle.com>

Alex Buckley wrote:
> On 4/4/2010 9:57 PM, Jonathan Gibbons wrote:
>> 2. Module resolution mode
>>
>> This refers to the way in which javac locates classes and resolves 
>> module dependencies. 
>
> Do you mean: "in which javac locates classes *of modules other than 
> the module for the compilation unit being compiled* and resolves 
> module dependencies *of the module for the compilation unit being 
> compiled*" ?

Being very pedantic, no, I did not mean what you said, because you 
seemed to limit the description to a single compilation unit, whereas I 
was trying to come up with a more general "big-picture" description.  If 
you were to pluralize the occurrences of "compilation unit" in your 
amended description, I would have less issue.


>
> I ask because I'm trying to work out where module-info.java fits in. 
> Oh wait, here it is:
>
>> In both modes, a module or modules found on the command line (either 
>> explicitly or on one of the available path options) will be taken 
>> into account by the module resolver, which will look for any 
>> unresolved dependencies in the system module library, or a library 
>> specified by the -L option.
>
> So you can supply one module-info.java file (3a) or multiple 
> module-info.java files (3b) on the command line, whether resolution is 
> done with Jigsaw (2a) or ZeroMod (2c).
Yes, that is a subset of what I was saying. You may also find 
module-info files on the class path, source path or module path.   But 
yes, the primary functionality difference between Jigsaw (2a) and 
ZeroMod (2c) is where unresolved modules are found (i.e. module 
libraries) and how the versions are handled

>
> If you supply zero module-info.java files on the command line, in 
> which modes will module-info.class be read silently to obtain 
> dependencies for normal compilation units supplied on the command line?

This is a function of the module resolution mode only.  module-info 
files will definitely be read in Jigsaw (2a) and ZeroMod (2c) modes. 
(2d) disables all module processing, so there will be no searching for 
module-info files. 294 RI is not yet supported, and it is TBD whether 
that mode is explicitly enabled with a new option, or whether it is the 
result of processing modules when no module-info files are to be found 
(in which case, what do we do if some but not all module-info files are 
found.)


>
> Alex



From jonathan.gibbons at oracle.com  Mon Apr  5 15:16:57 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 15:16:57 -0700
Subject: Please rview simple clean up of the modules build for javac
In-Reply-To: <4BBA5E55.4080803@oracle.com>
References: <4BBA4FC2.2060009@oracle.com> <4BBA58B9.80003@oracle.com>
	<4BBA5E55.4080803@oracle.com>
Message-ID: <4BBA6159.1050800@oracle.com>

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.

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.

-- 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 
>>>
>>>
>>>
>>
>



From alex.buckley at oracle.com  Mon Apr  5 17:05:53 2010
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 05 Apr 2010 17:05:53 -0700
Subject: Please rview simple clean up of the modules build for javac
In-Reply-To: <4BBA5E55.4080803@oracle.com>
References: <4BBA4FC2.2060009@oracle.com> <4BBA58B9.80003@oracle.com>
	<4BBA5E55.4080803@oracle.com>
Message-ID: <4BBA7AE1.3090705@oracle.com>

On 4/5/2010 3:04 PM, Mandy Chung wrote:
> Jonathan Gibbons wrote:
>> 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?

It is instructive to browse http://www.jarvana.com/jarvana/browse and 
see the names of projects in the central Maven repository. Maven 
identifies a module by a triple: groupId, artifactId, version. 
Paraphrasing "Maven: The Definitive Guide", the group identifier should 
be the reverse domain name of the creating organization (e.g. 
org.apache), and the artifact identifier should be the module name. This 
convention is not always followed; witness the commons-* groups. Even 
when the group identifier is a reverse domain name, it is sometimes 
suffixed by a sub-organization or product family, e.g. 
org.apache.lucene. Further, in a popular repository, the number of 
entries under 'org' or 'com' is so large that the additional top level 
provides little benefit. And in 2010, people search rather than 
classify; a module name arguably ought to reflect, more than anything 
else, the terms used in a search engine to find the module.

Since JDK modules only have name (+version), not group and artifact 
(+version), we must structure our names wisely. (Actually, avoiding 
group is a blessing, for reasons associated with JCP profiles that I 
shall not discuss here.)

Publicly distributed modules like the JDK should always have qualified 
names. I do not believe starting a module name with a reverse domain 
name is appropriate, because it obscures browsing module repositories 
and there are too many projects willing to ignore the convention. Using 
the commonly-searched-for product name such as 'jdk' as the first 
component seems ideal. Again, in 2010, the existence of large 
repositories means that picking a globally unique name is not so hard 
that it requires recourse to domain names.

Alex


From jonathan.gibbons at oracle.com  Mon Apr  5 18:27:56 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 18:27:56 -0700
Subject: -Xbootclasspath/p in the JDK build
Message-ID: <4BBA8E1C.7020008@oracle.com>

Aaaargh.

The restrictions on bootclasspath are going to be an issue for building 
JDK, because -Xbootclasspath/p is used in various places in the build 
itself.  In particular, this will be a problem when we set 
SKIP_BOOT_CYCLE=false, because the first time round, the BOOT_DIR will 
be set to JDK 6, and -Xbootclasspath/p can be used; the second time 
round, the BOOTDIR will be the newly built JDK 7, and -Xbootclasspath/p 
might not be available.

Here are places where I know -Xbootclasspath/p is used in the build.

1. In the langtools build.xml file.

The langtools build uses the BOOT_DIR javac to compile the new javac 
classes, then immediately uses those classes on the bootclasspath to 
recompile javac again, for use in the final product. This ensures that 
the javac in the final JDK is built with the latest sources (and not 
built with the BOOT_DIR javac.) Both the interim javac and the final 
javac are made available to the downstream parts of the build.

2. In the jdk Makefiles

The interim javac referred to in the previous section is used to compile 
most of the classes in the other repositories. This is done by setting 
JAVAC_CMD to use the BOOT_DIR javac with the newly compiled javac 
classes on the bootclasspath.


There are 3 ways forward that I can see.

1. Support -Xbootclasspath/p:  This is arguably simpler than supporting 
plain -Xbootclasspath.

2. Leave javac, javadoc, javah to run in JVM legacy mode so that  
-Xbootclasspath/p: continues to work for these tools. The latest 
versions of these tools are all used in the build using BOOT_DIR and 
-Xbootclasspath.

3. Figure out rules to examine BOOT_DIR and decide if -Xbootclasspath is 
going to be available, or if we need to build a temporary module library 
for use with the -L option. Note this will require us to address the 
issues with -L that I raised in [1].

In any case, if this has not already been implemented, I would recommend 
that the launcher should reject (give an error) options like 
-Xbootclasspath if it is not going to accept them. Silently ignoring the 
options if they are not applicable is almost certainly the wrong thing 
to do.

-- Jon

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html








From jonathan.gibbons at oracle.com  Mon Apr  5 18:38:23 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 18:38:23 -0700
Subject: -Xbootclasspath/p in the JDK build
In-Reply-To: <4BBA8E1C.7020008@oracle.com>
References: <4BBA8E1C.7020008@oracle.com>
Message-ID: <4BBA908F.6010409@oracle.com>

Jonathan Gibbons wrote:
> Aaaargh.
>
> The restrictions on bootclasspath are going to be an issue for 
> building JDK, because -Xbootclasspath/p is used in various places in 
> the build itself.  In particular, this will be a problem when we set 
> SKIP_BOOT_CYCLE=false, because the first time round, the BOOT_DIR will 
> be set to JDK 6, and -Xbootclasspath/p can be used; the second time 
> round, the BOOTDIR will be the newly built JDK 7, and 
> -Xbootclasspath/p might not be available.
>
> Here are places where I know -Xbootclasspath/p is used in the build.
>
> 1. In the langtools build.xml file.
>
> The langtools build uses the BOOT_DIR javac to compile the new javac 
> classes, then immediately uses those classes on the bootclasspath to 
> recompile javac again, for use in the final product. This ensures that 
> the javac in the final JDK is built with the latest sources (and not 
> built with the BOOT_DIR javac.) Both the interim javac and the final 
> javac are made available to the downstream parts of the build.
>
> 2. In the jdk Makefiles
>
> The interim javac referred to in the previous section is used to 
> compile most of the classes in the other repositories. This is done by 
> setting JAVAC_CMD to use the BOOT_DIR javac with the newly compiled 
> javac classes on the bootclasspath.
>
>
> There are 3 ways forward that I can see.
>
> 1. Support -Xbootclasspath/p:  This is arguably simpler than 
> supporting plain -Xbootclasspath.
>
> 2. Leave javac, javadoc, javah to run in JVM legacy mode so that  
> -Xbootclasspath/p: continues to work for these tools. The latest 
> versions of these tools are all used in the build using BOOT_DIR and 
> -Xbootclasspath.
>
> 3. Figure out rules to examine BOOT_DIR and decide if -Xbootclasspath 
> is going to be available, or if we need to build a temporary module 
> library for use with the -L option. Note this will require us to 
> address the issues with -L that I raised in [1].
>
> In any case, if this has not already been implemented, I would 
> recommend that the launcher should reject (give an error) options like 
> -Xbootclasspath if it is not going to accept them. Silently ignoring 
> the options if they are not applicable is almost certainly the wrong 
> thing to do.
>
> -- Jon
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html
>


There is probably another way forward, which may be the best way for the 
time being:

4. Examine BOOT_DIR to decide if modules are being used or not.  Then 
use -Xmode:legacy if necessary as well as -Xbootclasspath/p: to run the 
necessary tools in JVM legacy mode.


-- Jon


From mandy.chung at oracle.com  Mon Apr  5 19:14:43 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 19:14:43 -0700
Subject: -Xbootclasspath/p in the JDK build
In-Reply-To: <4BBA908F.6010409@oracle.com>
References: <4BBA8E1C.7020008@oracle.com> <4BBA908F.6010409@oracle.com>
Message-ID: <4BBA9913.6000403@oracle.com>

Jonathan Gibbons wrote:
> Jonathan Gibbons wrote:
>> Aaaargh.
>>
>> The restrictions on bootclasspath are going to be an issue for 
>> building JDK, because -Xbootclasspath/p is used in various places in 
>> the build itself.  In particular, this will be a problem when we set 
>> SKIP_BOOT_CYCLE=false, because the first time round, the BOOT_DIR 
>> will be set to JDK 6, and -Xbootclasspath/p can be used; the second 
>> time round, the BOOTDIR will be the newly built JDK 7, and 
>> -Xbootclasspath/p might not be available.
>>

I would imagine that it will take some time (probably the next release) 
to transition from the -Xbootclasspath/p to -L <module-lib> for 
SKIP_BOOT_CYCLE.    I think option #4 is the best way for the time being.
 
>> Here are places where I know -Xbootclasspath/p is used in the build.
>>
>> 1. In the langtools build.xml file.
>>
>> The langtools build uses the BOOT_DIR javac to compile the new javac 
>> classes, then immediately uses those classes on the bootclasspath to 
>> recompile javac again, for use in the final product. This ensures 
>> that the javac in the final JDK is built with the latest sources (and 
>> not built with the BOOT_DIR javac.) Both the interim javac and the 
>> final javac are made available to the downstream parts of the build.
>>
>> 2. In the jdk Makefiles
>>
>> The interim javac referred to in the previous section is used to 
>> compile most of the classes in the other repositories. This is done 
>> by setting JAVAC_CMD to use the BOOT_DIR javac with the newly 
>> compiled javac classes on the bootclasspath.
>>
>>
>> There are 3 ways forward that I can see.
>>
>> 1. Support -Xbootclasspath/p:  This is arguably simpler than 
>> supporting plain -Xbootclasspath.
>>
>> 2. Leave javac, javadoc, javah to run in JVM legacy mode so that  
>> -Xbootclasspath/p: continues to work for these tools. The latest 
>> versions of these tools are all used in the build using BOOT_DIR and 
>> -Xbootclasspath.
>>
>> 3. Figure out rules to examine BOOT_DIR and decide if -Xbootclasspath 
>> is going to be available, or if we need to build a temporary module 
>> library for use with the -L option. Note this will require us to 
>> address the issues with -L that I raised in [1].
>>
>> In any case, if this has not already been implemented, I would 
>> recommend that the launcher should reject (give an error) options 
>> like -Xbootclasspath if it is not going to accept them. 
It's already implemented.
   http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000715.html

Mandy
>> Silently ignoring the options if they are not applicable is almost 
>> certainly the wrong thing to do.
>>
>> -- Jon
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html
>>
>
>
> There is probably another way forward, which may be the best way for 
> the time being:
>
> 4. Examine BOOT_DIR to decide if modules are being used or not.  Then 
> use -Xmode:legacy if necessary as well as -Xbootclasspath/p: to run 
> the necessary tools in JVM legacy mode.
>
>
> -- Jon



From mandy.chung at oracle.com  Mon Apr  5 19:17:13 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 19:17:13 -0700
Subject: Please rview simple clean up of the modules build for javac
In-Reply-To: <4BBA6159.1050800@oracle.com>
References: <4BBA4FC2.2060009@oracle.com> <4BBA58B9.80003@oracle.com>
	<4BBA5E55.4080803@oracle.com> <4BBA6159.1050800@oracle.com>
Message-ID: <4BBA99A9.1020204@oracle.com>

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 
>>>>
>>>>
>>>>
>>>
>>
>



From jonathan.gibbons at oracle.com  Mon Apr  5 21:41:11 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Apr 2010 21:41:11 -0700
Subject: Please rview simple clean up of the modules build for javac
In-Reply-To: <4BBA99A9.1020204@oracle.com>
References: <4BBA4FC2.2060009@oracle.com> <4BBA58B9.80003@oracle.com>
	<4BBA5E55.4080803@oracle.com> <4BBA6159.1050800@oracle.com>
	<4BBA99A9.1020204@oracle.com>
Message-ID: <4BBABB67.4060501@oracle.com>

Mandy Chung wrote:
> 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?

Yes, but that's another new version of rmic we're wishing for (rmic 
-Xreallynew?)

>>
>> 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 
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From mandy.chung at oracle.com  Mon Apr  5 22:52:42 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 05 Apr 2010 22:52:42 -0700
Subject: Platform module for javac to locate classes from system module library
Message-ID: <4BBACC2A.7050704@oracle.com>

Jon, Mark,

There are two module compilation modes described in [1]:
   3.a) Single module mode
          3.a.i - compiling modular code (i.e. module-info.java exists)
          3.a.ii - compiling non-modular code (i.e. no module-info.java 
exists)
   3.b) Multi-module mode

In this context, I'm interested in the jigsaw mode (2.a) that asks the 
jigsaw resolver for module resolution and the system module library 
contains some platform modules.

For compiling modular code (single (3.a.i) or multiple (3.b) module 
mode), there is one or more module-info.java files on the command line.  
If the module-info.java doesn't specify a dependency on the platform 
modules, javac will use the default platform module to locate classes 
and resolve dependencies.   This sounds good so far (what the default 
platform module should be is a separate question).

When compiling non-modular code in single module mode (3.a.ii)), there 
is no module-info.java file explicitly specified on the command line and 
javac will need to read module-info from the system module library.   
I'd like this module resolution mode to provide equivalent functionality 
as "javac's legacy mode" such that it can locate all classes in the 
system module library regardless of what modules are installed (i.e. the 
default platform module might not exist).   For example, jdk-base-image 
only contains jdk.base module + jdk.logging + javac and its 
dependences.  I expect it can compile a simple program that uses 
java.util.logging API:
  $ cat Helloworld.java
     public class Helloworld {
          java.util.logging.Logger.getLogger("org.hello");
     }

  $ jdk-base-image/bin/javac Helloworld.java

In this case, the default platform module doesn't exist.  Additional 
modules can be installed in the system module library later.  Should 
this module resolution mode (3.a.ii) support a system module library of 
any installed module?  Or should this module resolution mode (3.a.ii) 
only be supported in the full jdk (i.e. equivalent to the legacy image)?

To support (3.a.ii) in a system module library of any installed module, 
one proposal is to have javac to use a module that can aggregate all 
modules installed in the system module library at any point in time for 
resolution instead of the default platform module.  For example, we can 
define a "jre.legacy" module that has optional dependences on all jre
modules and the jre.legacy is always installed in the base image.  This 
is described in the legacy boot loader approach [2].  For (3.a.i) mode, 
javac will use the default platform module.  For (3.a.ii) mode, javac 
will use the "jre.legacy" module.   Jon also explores the option of 
setting 'sun.boot.class.path" property.  I don't think we should rely on 
the existence of "sun.boot.class.path" property in the modular world.

Thanks
Mandy

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000763.html
[2] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000563.html


From jonathan.gibbons at oracle.com  Tue Apr  6 09:57:20 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 Apr 2010 09:57:20 -0700
Subject: Platform module for javac to locate classes from system module
	library
In-Reply-To: <4BBACC2A.7050704@oracle.com>
References: <4BBACC2A.7050704@oracle.com>
Message-ID: <4BBB67F0.90102@oracle.com>

Mandy,

I like the suggestion of using a module name such as jre.legacy for the 
situations like 3.a.ii when we are compiling legacy code with no 
module-info at all. (I'm not fussed about the exact name that you 
choose.) and when some sort of module resolver is in use.

I have a mild preference for sun.boot.class.path remaining available for 
"no modules" mode (2d), but the more we exercise and  use the preferred 
alternatives, the less important it becomes to have a fall back 
position, which is what -XDnomodules provides.

-- Jon


Mandy Chung wrote:
> Jon, Mark,
>
> There are two module compilation modes described in [1]:
>   3.a) Single module mode
>          3.a.i - compiling modular code (i.e. module-info.java exists)
>          3.a.ii - compiling non-modular code (i.e. no module-info.java 
> exists)
>   3.b) Multi-module mode
>
> In this context, I'm interested in the jigsaw mode (2.a) that asks the 
> jigsaw resolver for module resolution and the system module library 
> contains some platform modules.
>
> For compiling modular code (single (3.a.i) or multiple (3.b) module 
> mode), there is one or more module-info.java files on the command 
> line.  If the module-info.java doesn't specify a dependency on the 
> platform modules, javac will use the default platform module to locate 
> classes and resolve dependencies.   This sounds good so far (what the 
> default platform module should be is a separate question).
>
> When compiling non-modular code in single module mode (3.a.ii)), there 
> is no module-info.java file explicitly specified on the command line 
> and javac will need to read module-info from the system module 
> library.   I'd like this module resolution mode to provide equivalent 
> functionality as "javac's legacy mode" such that it can locate all 
> classes in the system module library regardless of what modules are 
> installed (i.e. the default platform module might not exist).   For 
> example, jdk-base-image only contains jdk.base module + jdk.logging + 
> javac and its dependences.  I expect it can compile a simple program 
> that uses java.util.logging API:
>  $ cat Helloworld.java
>     public class Helloworld {
>          java.util.logging.Logger.getLogger("org.hello");
>     }
>
>  $ jdk-base-image/bin/javac Helloworld.java
>
> In this case, the default platform module doesn't exist.  Additional 
> modules can be installed in the system module library later.  Should 
> this module resolution mode (3.a.ii) support a system module library 
> of any installed module?  Or should this module resolution mode 
> (3.a.ii) only be supported in the full jdk (i.e. equivalent to the 
> legacy image)?
>
> To support (3.a.ii) in a system module library of any installed 
> module, one proposal is to have javac to use a module that can 
> aggregate all modules installed in the system module library at any 
> point in time for resolution instead of the default platform module.  
> For example, we can define a "jre.legacy" module that has optional 
> dependences on all jre
> modules and the jre.legacy is always installed in the base image.  
> This is described in the legacy boot loader approach [2].  For (3.a.i) 
> mode, javac will use the default platform module.  For (3.a.ii) mode, 
> javac will use the "jre.legacy" module.   Jon also explores the option 
> of setting 'sun.boot.class.path" property.  I don't think we should 
> rely on the existence of "sun.boot.class.path" property in the modular 
> world.
>
> Thanks
> Mandy
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000763.html
> [2] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000563.html 
>



From mandy.chung at sun.com  Tue Apr  6 13:22:08 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Tue, 06 Apr 2010 20:22:08 +0000
Subject: hg: jigsaw/jigsaw/jdk: Minor cleanup to the modules.config and
	modules build for javac and other tools
Message-ID: <20100406202245.644974441C@hg.openjdk.java.net>

Changeset: 50e22887d332
Author:    mchung
Date:      2010-04-06 13:21 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/50e22887d332

Minor cleanup to the modules.config and modules build for javac and other tools
Reviewed-by: jjg

! make/modules/Makefile
! make/modules/modules.config
! make/modules/modules.group
! make/modules/tools/Makefile



From jonathan.gibbons at oracle.com  Tue Apr  6 18:53:45 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 Apr 2010 18:53:45 -0700
Subject: Sigh, bootclasspath again
Message-ID: <4BBBE5A9.5020700@oracle.com>

Is -Xbootclasspath/p: supported in JVM legacy mode?

I'm beginning to suspect it is not. Can anyone confirm one way or the other?

-- Jon



From jonathan.gibbons at oracle.com  Tue Apr  6 19:01:53 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 Apr 2010 19:01:53 -0700
Subject: Sigh, bootclasspath again
In-Reply-To: <4BBBE5A9.5020700@oracle.com>
References: <4BBBE5A9.5020700@oracle.com>
Message-ID: <4BBBE791.3020600@oracle.com>

Jonathan Gibbons wrote:
> Is -Xbootclasspath/p: supported in JVM legacy mode?
>
> I'm beginning to suspect it is not. Can anyone confirm one way or the 
> other?
>
> -- Jon
>
I have proof that it is not, for those that want to wade through the 
debugging output from my test. This is a big deal bug.

-- Jon


From Weijun.Wang at Sun.COM  Tue Apr  6 19:13:52 2010
From: Weijun.Wang at Sun.COM (Weijun Wang)
Date: Wed, 07 Apr 2010 10:13:52 +0800
Subject: Sigh, bootclasspath again
In-Reply-To: <4BBBE791.3020600@oracle.com>
References: <4BBBE5A9.5020700@oracle.com> <4BBBE791.3020600@oracle.com>
Message-ID: <6E4D312E-6288-40A2-9372-9AE3C57C636B@sun.com>

Is there any workaround to this? Say, compile your several classes into another module which is nearer to core than core.jar itself?

I often create a small jar and tell the customer to try it with -Xbootclasspath/p: before I finalize a fix.

-- Max

On Apr 7, 2010, at 10:01 AM, Jonathan Gibbons wrote:

> Jonathan Gibbons wrote:
>> Is -Xbootclasspath/p: supported in JVM legacy mode?
>> 
>> I'm beginning to suspect it is not. Can anyone confirm one way or the other?
>> 
>> -- Jon
>> 
> I have proof that it is not, for those that want to wade through the debugging output from my test. This is a big deal bug.
> 
> -- Jon



From mandy.chung at oracle.com  Tue Apr  6 19:22:19 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 06 Apr 2010 19:22:19 -0700
Subject: Sigh, bootclasspath again
In-Reply-To: <4BBBE791.3020600@oracle.com>
References: <4BBBE5A9.5020700@oracle.com> <4BBBE791.3020600@oracle.com>
Message-ID: <4BBBEC5B.9020201@oracle.com>

Jonathan Gibbons wrote:
> Jonathan Gibbons wrote:
>> Is -Xbootclasspath/p: supported in JVM legacy mode?
>>
>> I'm beginning to suspect it is not. Can anyone confirm one way or the 
>> other?
>>
>> -- Jon
>>
> I have proof that it is not, for those that want to wade through the 
> debugging output from my test. This is a big deal bug.
>

-Xbootclasspath/p: is expected to work in JVM legacy mode as it is.  In 
JVM legacy mode, the launcher sets -Xbootclasspath/p:<list of all 
modules> and passes it to the VM.  I set _JAVA_LAUNCHER_DEBUG 
environment variable and confirms that the user-specified 
-Xbootclasspath/p: and the -Xbootclasspath/p: computed by the launcher 
are passed to the JVM.

The VM should be able to take one or more -Xbootclasspath/p options.  
I'll need to investigate further.

Mandy


From jonathan.gibbons at oracle.com  Tue Apr  6 19:35:52 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 Apr 2010 19:35:52 -0700
Subject: Sigh, bootclasspath again
In-Reply-To: <4BBBEC5B.9020201@oracle.com>
References: <4BBBE5A9.5020700@oracle.com> <4BBBE791.3020600@oracle.com>
	<4BBBEC5B.9020201@oracle.com>
Message-ID: <4BBBEF88.8040500@oracle.com>

Mandy Chung wrote:
> Jonathan Gibbons wrote:
>> Jonathan Gibbons wrote:
>>> Is -Xbootclasspath/p: supported in JVM legacy mode?
>>>
>>> I'm beginning to suspect it is not. Can anyone confirm one way or 
>>> the other?
>>>
>>> -- Jon
>>>
>> I have proof that it is not, for those that want to wade through the 
>> debugging output from my test. This is a big deal bug.
>>
>
> -Xbootclasspath/p: is expected to work in JVM legacy mode as it is.  
> In JVM legacy mode, the launcher sets -Xbootclasspath/p:<list of all 
> modules> and passes it to the VM.  I set _JAVA_LAUNCHER_DEBUG 
> environment variable and confirms that the user-specified 
> -Xbootclasspath/p: and the -Xbootclasspath/p: computed by the launcher 
> are passed to the JVM.
>
> The VM should be able to take one or more -Xbootclasspath/p options.  
> I'll need to investigate further.
>
> Mandy

Mandy,

Thanks, I'll try using that _JAVA_LAUNCHER_DEBUG variable and see what 
output I get.

 From my tests, I saw that my environment worked (a test behaved as 
expected) using a recent 1.7.0 build, but not with the latest Jigsaw 
jdk-modules-image. Printing out the URL for javac's entry class and 
printing sun.boot.class.path seemed to indicate -Xbootclasspath was not 
being handled.

-- Jon


From lfrlsantos at gmail.com  Tue Apr  6 19:40:15 2010
From: lfrlsantos at gmail.com (Luis Santos)
Date: Wed, 7 Apr 2010 03:40:15 +0100
Subject: Some questions regardind project Jigsaw
Message-ID: <v2uae18ee9d1004061940u4ba07286rfbffc86f511392a8@mail.gmail.com>

I'm sorry posting here these questions. I tried to read everything i can but
found no definitive responses to my doubts. I'm doing a cientific study
based on modularity in java language and i stoped at JSR294/Jigsaw doubts.
This is an academic study and when i selected this study about 8 months ago,
i tought direction would be Jigsaw project to be incorporated in JDK7. My
intention is to try to demonstrate necessity of having a modular system
implemented in java language. My doubts are based on that my initial tittle
was regardind modularity proposed by jigsaw project. For what i have read
recently, Jigsaw is only a reference implementation (i don't know if this is
true) of JSR204 and the "true" modular specification actually being accepted
is JSt204. IS this the correct interpretation? How does Jigsaw project
relaets to Modules Project? Thank you very much for yout attention.

Luis Santos


From mandy.chung at oracle.com  Tue Apr  6 19:55:10 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 06 Apr 2010 19:55:10 -0700
Subject: More jigsaw cleanup
Message-ID: <4BBBF40E.8080109@oracle.com>

I'm going to push this set of minor fixes:
- clean up modules.config and modules.group
- ClassLoader - remove the hackBootPath done for J1 demo
- fix jigsaw jtreg tests to run on Windows.

Webrev:
   http://cr.openjdk.java.net/~mchung/jigsaw/more-cleanup/

Thanks
Mandy


From jonathan.gibbons at oracle.com  Tue Apr  6 20:05:47 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 Apr 2010 20:05:47 -0700
Subject: More jigsaw cleanup
In-Reply-To: <4BBBF40E.8080109@oracle.com>
References: <4BBBF40E.8080109@oracle.com>
Message-ID: <4BBBF68B.9020100@oracle.com>

Mandy Chung wrote:
> I'm going to push this set of minor fixes:
> - clean up modules.config and modules.group
> - ClassLoader - remove the hackBootPath done for J1 demo
> - fix jigsaw jtreg tests to run on Windows.
>
> Webrev:
>   http://cr.openjdk.java.net/~mchung/jigsaw/more-cleanup/
>
> Thanks
> Mandy
Looks good.

-- Jon


From alex.buckley at oracle.com  Tue Apr  6 20:07:12 2010
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 06 Apr 2010 20:07:12 -0700
Subject: Some questions regardind project Jigsaw
In-Reply-To: <v2uae18ee9d1004061940u4ba07286rfbffc86f511392a8@mail.gmail.com>
References: <v2uae18ee9d1004061940u4ba07286rfbffc86f511392a8@mail.gmail.com>
Message-ID: <4BBBF6E0.8080209@oracle.com>

Luis,

The need for the Jigsaw module system is documented at 
http://blogs.sun.com/mr/entry/jigsaw. (Be sure to follow all the links 
in that article!)

It is important to understand the difference between the Jigsaw module 
system and JSR 294:

- Jigsaw is a module system, outside the Java language and VM.

- JSR 294 is a set of language and VM changes to support module systems 
such as Jigsaw and OSGi.

- Jigsaw does not depend on JSR 294 at the present time.

- JSR 294 does not depend on Jigsaw.

- The OpenJDK project called Jigsaw hosts a) the Reference 
Implementation of JSR 294, and b) discusses the design and 
implementation of the Jigsaw module system, and c) discusses JDK 
modularization.

- More detail about the relationship of the Jigsaw module system and JSR 
294 can be found in the PDF linked to from my blog entry: 
http://blogs.sun.com/abuckley/en_US/entry/jsr_294_and_module_systems

Alex

P.S. The OpenJDK Modules project is not relevant. Nor is JSR 277, before 
you ask about that. Forget you ever heard of them.

On 4/6/2010 7:40 PM, Luis Santos wrote:
> I'm sorry posting here these questions. I tried to read everything i can but
> found no definitive responses to my doubts. I'm doing a cientific study
> based on modularity in java language and i stoped at JSR294/Jigsaw doubts.
> This is an academic study and when i selected this study about 8 months ago,
> i tought direction would be Jigsaw project to be incorporated in JDK7. My
> intention is to try to demonstrate necessity of having a modular system
> implemented in java language. My doubts are based on that my initial tittle
> was regardind modularity proposed by jigsaw project. For what i have read
> recently, Jigsaw is only a reference implementation (i don't know if this is
> true) of JSR204 and the "true" modular specification actually being accepted
> is JSt204. IS this the correct interpretation? How does Jigsaw project
> relaets to Modules Project? Thank you very much for yout attention.
> 
> Luis Santos


From jonathan.gibbons at oracle.com  Tue Apr  6 20:14:31 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 Apr 2010 20:14:31 -0700
Subject: Sigh, bootclasspath again
In-Reply-To: <6E4D312E-6288-40A2-9372-9AE3C57C636B@sun.com>
References: <4BBBE5A9.5020700@oracle.com> <4BBBE791.3020600@oracle.com>
	<6E4D312E-6288-40A2-9372-9AE3C57C636B@sun.com>
Message-ID: <4BBBF897.2060105@oracle.com>

Weijun Wang wrote:
> Is there any workaround to this? Say, compile your several classes into another module which is nearer to core than core.jar itself?
>
> I often create a small jar and tell the customer to try it with -Xbootclasspath/p: before I finalize a fix.
>
> -- Max
>
> On Apr 7, 2010, at 10:01 AM, Jonathan Gibbons wrote:
>
>   
>> Jonathan Gibbons wrote:
>>     
>>> Is -Xbootclasspath/p: supported in JVM legacy mode?
>>>
>>> I'm beginning to suspect it is not. Can anyone confirm one way or the other?
>>>
>>> -- Jon
>>>
>>>       
>> I have proof that it is not, for those that want to wade through the debugging output from my test. This is a big deal bug.
>>
>> -- Jon
>>     
>
>   

Max,

In legacy mode, -Xbootclasspath/p: is supposed to work, so if it doesn't 
work, that's a bug that needs to be fixed. In the new modules mode, you 
would be able to deliver a new copy of an updated module, which could 
either be installed in the system library, or you could install it by 
itself in a temporary library using the main library as the parent. You 
could then run your code with -L tempLib must as you would do 
-Xbootclasspath/p: now.

Eventually, it will all be much better. What you are seeing here on this 
-dev list is the pain of transitioning to that world, where we have code 
and tools that do not know about or use the new features yet, and worse, 
code and tools which needs to be somewhat bimodal for the time being.

-- Jon


From mandy.chung at sun.com  Tue Apr  6 20:33:22 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 03:33:22 +0000
Subject: hg: jigsaw/jigsaw/jdk: More cleanup on modules.config,
	jigsaw jtreg tests to run on Windows, etc
Message-ID: <20100407033425.3C41844427@hg.openjdk.java.net>

Changeset: b4826091ca5e
Author:    mchung
Date:      2010-04-06 20:32 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b4826091ca5e

More cleanup on modules.config, jigsaw jtreg tests to run on Windows, etc
Reviewed-by: jjg

! make/modules/modules.config
! make/modules/modules.group
! src/share/classes/java/lang/ClassLoader.java
! test/org/openjdk/jigsaw/_Library.java
! test/org/openjdk/jigsaw/library.sh
! test/org/openjdk/jigsaw/resource.sh
! test/org/openjdk/jigsaw/tester.sh



From mr at sun.com  Tue Apr  6 20:42:36 2010
From: mr at sun.com (Mark Reinhold)
Date: Tue, 06 Apr 2010 20:42:36 -0700
Subject: More jigsaw cleanup 
In-Reply-To: mandy.chung@oracle.com; Tue, 06 Apr 2010 19:55:10 PDT;
	<4BBBF40E.8080109@oracle.com> 
Message-ID: <20100407034236.24002A01@eggemoggin.niobe.net>

> Date: Tue, 06 Apr 2010 19:55:10 -0700
> From: mandy.chung at oracle.com

> I'm going to push this set of minor fixes:
> - clean up modules.config and modules.group
> - ClassLoader - remove the hackBootPath done for J1 demo

Good!  Nice to see that particular hack gone.

- Mark


From Alan.Bateman at Sun.COM  Wed Apr  7 00:35:48 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 07 Apr 2010 08:35:48 +0100
Subject: More jigsaw cleanup
In-Reply-To: <4BBBF40E.8080109@oracle.com>
References: <4BBBF40E.8080109@oracle.com>
Message-ID: <4BBC35D4.6040605@sun.com>

Mandy Chung wrote:
> I'm going to push this set of minor fixes:
> - clean up modules.config and modules.group
> - ClassLoader - remove the hackBootPath done for J1 demo
> - fix jigsaw jtreg tests to run on Windows.
>
> Webrev:
>   http://cr.openjdk.java.net/~mchung/jigsaw/more-cleanup/
>
> Thanks
> Mandy
The module updates looks good to me but I think you will need to update 
make/sql/Makefile, make/javax/sql/Makefile, and make/sun/rowset/Makefile 
to match the definitions.

-Alan


From mandy.chung at oracle.com  Wed Apr  7 07:13:14 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 07 Apr 2010 07:13:14 -0700
Subject: More jigsaw cleanup
In-Reply-To: <4BBC35D4.6040605@sun.com>
References: <4BBBF40E.8080109@oracle.com> <4BBC35D4.6040605@sun.com>
Message-ID: <4BBC92FA.4030107@oracle.com>

Alan Bateman wrote:
> Mandy Chung wrote:
>> I'm going to push this set of minor fixes:
>> - clean up modules.config and modules.group
>> - ClassLoader - remove the hackBootPath done for J1 demo
>> - fix jigsaw jtreg tests to run on Windows.
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/jigsaw/more-cleanup/
>>
>> Thanks
>> Mandy
> The module updates looks good to me but I think you will need to 
> update make/sql/Makefile, make/javax/sql/Makefile, and 
> make/sun/rowset/Makefile to match the definitions.

Thanks for catching it.  How can  I forget that!   The makefile changes are:

  http://cr.openjdk.java.net/~mchung/jigsaw/more-cleanup.01/

Thanks
Mandy



From Alan.Bateman at Sun.COM  Wed Apr  7 07:22:12 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 07 Apr 2010 15:22:12 +0100
Subject: More jigsaw cleanup
In-Reply-To: <4BBC92FA.4030107@oracle.com>
References: <4BBBF40E.8080109@oracle.com> <4BBC35D4.6040605@sun.com>
	<4BBC92FA.4030107@oracle.com>
Message-ID: <4BBC9514.8020903@sun.com>

Mandy Chung wrote:
> :
> Thanks for catching it.  How can  I forget that!   The makefile 
> changes are:
>
>  http://cr.openjdk.java.net/~mchung/jigsaw/more-cleanup.01/
Looks good - thanks!

-Alan


From mandy.chung at sun.com  Wed Apr  7 07:57:08 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 14:57:08 +0000
Subject: hg: jigsaw/jigsaw/jdk: Update MODULE variables in defined in
	makefiles to match modules.config
Message-ID: <20100407145754.8343644432@hg.openjdk.java.net>

Changeset: 87ebe2360cda
Author:    mchung
Date:      2010-04-07 07:56 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/87ebe2360cda

Update MODULE variables in defined in makefiles to match modules.config

! make/com/sun/rowset/Makefile
! make/java/nio/Makefile
! make/java/sql/Makefile
! make/javax/sql/Makefile



From mandy.chung at sun.com  Wed Apr  7 09:47:07 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 16:47:07 +0000
Subject: hg: jigsaw/jigsaw: jigsaw-b02
Message-ID: <20100407164708.0F1CA4443A@hg.openjdk.java.net>

Changeset: bef3965ce4a8
Author:    mchung
Date:      2010-04-07 09:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/rev/bef3965ce4a8

jigsaw-b02

! .hgtags



From mandy.chung at sun.com  Wed Apr  7 09:47:11 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 16:47:11 +0000
Subject: hg: jigsaw/jigsaw/corba: jigsaw-b02
Message-ID: <20100407164714.B8FEF4443B@hg.openjdk.java.net>

Changeset: 4a3fb3218e31
Author:    mchung
Date:      2010-04-07 09:26 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/4a3fb3218e31

jigsaw-b02

! .hgtags



From mandy.chung at sun.com  Wed Apr  7 09:47:19 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 16:47:19 +0000
Subject: hg: jigsaw/jigsaw/hotspot: jigsaw-b02
Message-ID: <20100407164734.9F7874443C@hg.openjdk.java.net>

Changeset: f59c81b1afe9
Author:    mchung
Date:      2010-04-07 09:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/f59c81b1afe9

jigsaw-b02

! .hgtags



From mandy.chung at sun.com  Wed Apr  7 09:47:40 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 16:47:40 +0000
Subject: hg: jigsaw/jigsaw/jaxp: jigsaw-b02
Message-ID: <20100407164740.7F0224443D@hg.openjdk.java.net>

Changeset: a45dbf8ee934
Author:    mchung
Date:      2010-04-07 09:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/a45dbf8ee934

jigsaw-b02

! .hgtags



From mandy.chung at sun.com  Wed Apr  7 09:47:44 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 16:47:44 +0000
Subject: hg: jigsaw/jigsaw/jaxws: jigsaw-b02
Message-ID: <20100407164747.776924443E@hg.openjdk.java.net>

Changeset: 5b453e0d76e4
Author:    mchung
Date:      2010-04-07 09:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/5b453e0d76e4

jigsaw-b02

! .hgtags



From mandy.chung at sun.com  Wed Apr  7 09:47:52 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 07 Apr 2010 16:47:52 +0000
Subject: hg: jigsaw/jigsaw/jdk: jigsaw-b02
Message-ID: <20100407164842.B424B4443F@hg.openjdk.java.net>

Changeset: a91146dde1aa
Author:    mchung
Date:      2010-04-07 09:26 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a91146dde1aa

jigsaw-b02

! .hgtags



From Sean.Mullan at Sun.COM  Wed Apr  7 12:37:50 2010
From: Sean.Mullan at Sun.COM (Sean Mullan)
Date: Wed, 07 Apr 2010 15:37:50 -0400
Subject: Module URL
Message-ID: <4BBCDF0E.6030702@sun.com>

We need to retain the URL of the repository from which a module was retrieved to 
properly construct the CodeSource and ProtectionDomain for classes in that 
module. Is this information stored somewhere in the library?

Thanks,
Sean


From mr at sun.com  Wed Apr  7 13:30:28 2010
From: mr at sun.com (Mark Reinhold)
Date: Wed, 07 Apr 2010 13:30:28 -0700
Subject: Module URL 
In-Reply-To: sean.mullan@sun.com; Wed, 07 Apr 2010 15:37:50 EDT;
	<4BBCDF0E.6030702@sun.com> 
Message-ID: <20100407203028.3DDC7450@eggemoggin.niobe.net>

> Date: Wed, 07 Apr 2010 15:37:50 -0400
> From: sean.mullan at sun.com

> We need to retain the URL of the repository from which a module was retrieved
> to properly construct the CodeSource and ProtectionDomain for classes in that
> module. Is this information stored somewhere in the library?

No, not at the moment.

In general a module may be downloaded from a repository other than the
one in which it was originally published, and modules from different
repositories may need to wind up in the same protection domain.

Can't we just leave the CodeSource location property unspecified, i.e.,
null?

- Mark


From sean.mullan at oracle.com  Wed Apr  7 13:58:47 2010
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 07 Apr 2010 16:58:47 -0400
Subject: Module URL
In-Reply-To: <20100407203028.3DDC7450@eggemoggin.niobe.net>
References: <20100407203028.3DDC7450@eggemoggin.niobe.net>
Message-ID: <4BBCF207.80200@oracle.com>

Mark Reinhold wrote:
>> Date: Wed, 07 Apr 2010 15:37:50 -0400
>> From: sean.mullan at sun.com
> 
>> We need to retain the URL of the repository from which a module was retrieved
>> to properly construct the CodeSource and ProtectionDomain for classes in that
>> module. Is this information stored somewhere in the library?
> 
> No, not at the moment.
> 
> In general a module may be downloaded from a repository other than the
> one in which it was originally published, and modules from different
> repositories may need to wind up in the same protection domain.
> 
> Can't we just leave the CodeSource location property unspecified, i.e.,
> null?

Hmm. In the signed module design, we are binding the granted permissions to the 
module at installation time. So it should be possible to simply instantiate the 
ProtectionDomain with an unspecified CodeSource and a static set of granted 
permissions at runtime. Will need to look into that more.

However, in some cases we'll need the URL at install time for security purposes. 
Unsigned modules packaged as web applications will need to be sandboxed. Network 
access is by default limited to connections back to the host, and is based on 
the CodeSource URL (see URLClassLoader.getPermissions(CodeSource)). What URL 
should I use in that case in order to grant a SocketPermission to that unsigned 
module?

--Sean


From Mandy.Chung at Sun.COM  Wed Apr  7 14:48:00 2010
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Wed, 07 Apr 2010 14:48:00 -0700
Subject: Sigh, bootclasspath again
In-Reply-To: <4BBBEC5B.9020201@oracle.com>
References: <4BBBE5A9.5020700@oracle.com> <4BBBE791.3020600@oracle.com>
	<4BBBEC5B.9020201@oracle.com>
Message-ID: <4BBCFD90.1080809@Sun.com>

Hi Jon,

It's a bug in the launcher that adds -Xbootclasspath/p: for legacy mode 
as the last VM argument. Hotspot VM prepends the given 
-Xbootclasspath/p: argument to the bootclasspath in the order of the 
input VM arguments.  That's why the classes in the system module library 
always get loaded but not the command-line -Xbootclasspath/p: argument.

http://cr.openjdk.java.net/~mchung/jigsaw/bootclasspath-prepend-fix/

I tested this javac command that picks up the javac classes from 
langtools/dist/lib/classes.jar.

$ jdk-module-image/bin/javac 
-J-Xbootclasspath/p:langtools/dist/lib/classes.jar -J-verbose:class -version

Mandy

Mandy Chung wrote:
> Jonathan Gibbons wrote:
>> Jonathan Gibbons wrote:
>>> Is -Xbootclasspath/p: supported in JVM legacy mode?
>>>
>>> I'm beginning to suspect it is not. Can anyone confirm one way or the 
>>> other?
>>>
>>> -- Jon
>>>
>> I have proof that it is not, for those that want to wade through the 
>> debugging output from my test. This is a big deal bug.
>>
> 
> -Xbootclasspath/p: is expected to work in JVM legacy mode as it is.  In 
> JVM legacy mode, the launcher sets -Xbootclasspath/p:<list of all 
> modules> and passes it to the VM.  I set _JAVA_LAUNCHER_DEBUG 
> environment variable and confirms that the user-specified 
> -Xbootclasspath/p: and the -Xbootclasspath/p: computed by the launcher 
> are passed to the JVM.
> 
> The VM should be able to take one or more -Xbootclasspath/p options.  
> I'll need to investigate further.
> 
> Mandy



From david.lloyd at redhat.com  Wed Apr  7 18:27:25 2010
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 07 Apr 2010 20:27:25 -0500
Subject: Module URL
In-Reply-To: <4BBCF207.80200@oracle.com>
References: <20100407203028.3DDC7450@eggemoggin.niobe.net>
	<4BBCF207.80200@oracle.com>
Message-ID: <4BBD30FD.6030302@redhat.com>

If it helps, I have implemented something similar.  I use a module scheme 
like this:

     module:<group>:<name>[:<versionSlot>][/resource/root][?resource/path]

and in the case of code source, we use just the module identifier part (up 
to and including the optional version slot).  Thus, code source is defined 
in terms of the module only, with no relationship to where the code 
actually came from (i.e. the module loader is trusted).

On 04/07/2010 03:58 PM, Sean Mullan wrote:
> Mark Reinhold wrote:
>>> Date: Wed, 07 Apr 2010 15:37:50 -0400
>>> From: sean.mullan at sun.com
>>
>>> We need to retain the URL of the repository from which a module was
>>> retrieved
>>> to properly construct the CodeSource and ProtectionDomain for classes
>>> in that
>>> module. Is this information stored somewhere in the library?
>>
>> No, not at the moment.
>>
>> In general a module may be downloaded from a repository other than the
>> one in which it was originally published, and modules from different
>> repositories may need to wind up in the same protection domain.
>>
>> Can't we just leave the CodeSource location property unspecified, i.e.,
>> null?
>
> Hmm. In the signed module design, we are binding the granted permissions
> to the module at installation time. So it should be possible to simply
> instantiate the ProtectionDomain with an unspecified CodeSource and a
> static set of granted permissions at runtime. Will need to look into
> that more.
>
> However, in some cases we'll need the URL at install time for security
> purposes. Unsigned modules packaged as web applications will need to be
> sandboxed. Network access is by default limited to connections back to
> the host, and is based on the CodeSource URL (see
> URLClassLoader.getPermissions(CodeSource)). What URL should I use in
> that case in order to grant a SocketPermission to that unsigned module?
>
> --Sean

-- 
- DML ?


From mandy.chung at sun.com  Wed Apr  7 20:18:02 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Thu, 08 Apr 2010 03:18:02 +0000
Subject: hg: jigsaw/jigsaw/jdk: Fix launcher to take -Xbootclasspath/p:
	argument properly
Message-ID: <20100408031849.20D024444C@hg.openjdk.java.net>

Changeset: a4da6b3472f4
Author:    mchung
Date:      2010-04-07 20:09 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a4da6b3472f4

Fix launcher to take -Xbootclasspath/p: argument properly
And fix for importing corba from jdk-module-image for SKIP_BOOT_CYCLE=false

! make/common/internal/Defs-corba.gmk
! make/modules/Makefile
! make/modules/modules.config
! make/sun/rmi/rmid/Makefile
! src/share/bin/java.c
! test/org/openjdk/jigsaw/library.sh



From mandy.chung at oracle.com  Fri Apr  9 23:03:15 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 09 Apr 2010 23:03:15 -0700
Subject: Remove an older hack in hotspot for booting in legacy mode
Message-ID: <4BC014A3.2030906@oracle.com>

Mark, Karen,

When running from jdk build/<os>-<arch>/bin/java (where it has the 
"classes" directory), in legacy mode, when I recompile the jdk classes 
without updating the system module library, the VM will load the older 
copy in the module library instead of the build/classes directory since 
the boot module is hardcoded in the VM default bootclasspath.

This fix will remove this older hack put in hotspot to hardcode the boot 
module in the bootclasspath for legacy mode running in a module image.  
It's replaced by a recent hack I put in the launcher to prepend all 
modules in the system module library in the bootclasspath.

The change only impacts legacy mode.  In the module mode,  the 
bootclasspath is set differently (line 870-907) to the value of the 
sun.java.launcher.module.boot property (that is set by the launcher).  
It continues to work as it is.

Webrev at:
  http://cr.openjdk.java.net/~mchung/jigsaw/hotspot-sjlmb/

Thanks
Mandy



From Alan.Bateman at oracle.com  Mon Apr 19 06:26:49 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Apr 2010 14:26:49 +0100
Subject: Library delegation - should the path to parent library be the
	canonical path?
Message-ID: <4BCC5A19.6070702@oracle.com>

I've been playing with the module library delegation and it looks to me 
that the path to the parent library is stored as the canonical path at 
the time that the library is created. I wonder if this will be a 
problem. Say in a cluster where the canonical path might differ 
depending on which node that has mounted the file system. Also, I assume 
it means that a library cannot be moved to a different location. On 
that, does jmod need a "reparent" command to aid fix up in the event 
that a library is moved?

-Alan.


From jonathan.gibbons at oracle.com  Tue Apr 20 08:14:15 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 20 Apr 2010 16:14:15 +0100
Subject: jmod request
Message-ID: <4BCDC4C7.8090207@oracle.com>

It seems that if a module has been installed, it cannot be replaced by 
installing it again.

Is there any chance of getting "remove" or "uninstall" options for jmod, 
or even the ability to reinstall a module.  Now that we can build all 
the modules for JDK, it would be very helpful to be able to install new 
modules without rebuilding JDK.

As a short term work around, it appears to work to delete the 
appropriate directory with an "rm" command.   Is this likely OK, or 
likely to cause horrors in the minds of the folk that understand module 
libraries?

-- Jon


From mandy.chung at oracle.com  Tue Apr 20 09:05:41 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 20 Apr 2010 09:05:41 -0700
Subject: jmod request
In-Reply-To: <4BCDC4C7.8090207@oracle.com>
References: <4BCDC4C7.8090207@oracle.com>
Message-ID: <4BCDD0D5.4080804@oracle.com>

Jonathan Gibbons wrote:
> It seems that if a module has been installed, it cannot be replaced by 
> installing it again.
>
> Is there any chance of getting "remove" or "uninstall" options for 
> jmod, or even the ability to reinstall a module.  Now that we can 
> build all the modules for JDK, it would be very helpful to be able to 
> install new modules without rebuilding JDK.
>
Mark has some change in the jmod command in his repository but I'm not 
sure if he already adds the "remove" "uninstall", or "reinstall" 
option.  If not, I will file a RFE and implement that.
> As a short term work around, it appears to work to delete the 
> appropriate directory with an "rm" command.   Is this likely OK, or 
> likely to cause horrors in the minds of the folk that understand 
> module libraries?
>
This workaround is fine.

Mandy


From mandy.chung at oracle.com  Tue Apr 20 14:33:50 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 20 Apr 2010 14:33:50 -0700
Subject: ModuleInfo extends AnnotatedElement
Message-ID: <4BCE1DBE.6020007@oracle.com>

The current API only supports to read annotations of a module when the 
module has been installed by using the java.lang.reflect.Module API 
(that extends AnnotatedElement).   There are cases that one would want 
to read the annotations from module-info while the module is being 
installed.  For example, a module can include some annotation to specify 
the installation requirement that can be used to determine if the module 
installation should continue based on the system configuration.  It is 
an opportunity to eliminate  transfers of the entire module and its 
dependencies if not needed.

We need to provide an API to read the annotations from module-info but 
the module may not be installed or downloaded at all.

One proposal is to extend java.lang.module.ModuleInfo to extend 
AnnotatedElement:
 
http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html

It will not load any classes referenced by annotations for this 
ModuleInfo until the getAnnotation or other method specified in the 
AnnotatedElement interface is called (since those classes might not 
exist or be found by the class loader).  In other word, this change will 
not affect the current module loading/resolution.   It will use the 
current module class loader to find classes to construct the Annotation 
objects.   If the type of an annotation's element cannot be found,  it 
will result in a TypeNotPresentException in the current proposed 
specification.  TypeNotPresentException is an unchecked exception and 
perhaps it'd be better to throw a checked exception.

Any comment, opinion?

Joe, your feedback would be helpful.

Thanks
Mandy


From joe.darcy at oracle.com  Tue Apr 20 17:48:31 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 20 Apr 2010 17:48:31 -0700
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BCE1DBE.6020007@oracle.com>
References: <4BCE1DBE.6020007@oracle.com>
Message-ID: <4BCE4B5F.6090509@oracle.com>

Hello.

On 4/20/2010 2:33 PM, Mandy Chung wrote:
> The current API only supports to read annotations of a module when the 
> module has been installed by using the java.lang.reflect.Module API 
> (that extends AnnotatedElement).   There are cases that one would want 
> to read the annotations from module-info while the module is being 
> installed.  For example, a module can include some annotation to 
> specify the installation requirement that can be used to determine if 
> the module installation should continue based on the system 
> configuration.  It is an opportunity to eliminate  transfers of the 
> entire module and its dependencies if not needed.
>
> We need to provide an API to read the annotations from module-info but 
> the module may not be installed or downloaded at all.
>
> One proposal is to extend java.lang.module.ModuleInfo to extend 
> AnnotatedElement:
>
> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html 
>
>
> It will not load any classes referenced by annotations for this 
> ModuleInfo until the getAnnotation or other method specified in the 
> AnnotatedElement interface is called (since those classes might not 
> exist or be found by the class loader).  In other word, this change 
> will not affect the current module loading/resolution.   It will use 
> the current module class loader to find classes to construct the 
> Annotation objects.   If the type of an annotation's element cannot be 
> found,  it will result in a TypeNotPresentException in the current 
> proposed specification.  TypeNotPresentException is an unchecked 
> exception and perhaps it'd be better to throw a checked exception.
>
> Any comment, opinion?
>
> Joe, your feedback would be helpful.

Mandy and I spoke about this issue.

In this situation, I recommend using a type other than the core 
reflection type to model the module, as is already being proposed with 
ModuleInfo.  Additionally, I recommend that ModuleInfo just implement a 
selected subset of the methods of AnnotatedElement, say, 
isAnnotationPresent and getAnnotation, and *not* implement the full 
interface.

This is part of the approach taken by JSR 269 to address a similar 
situation of reading annotations from contexts that are not necessarily 
at runtime after all the relevant classes are loaded.  In JSR 269, types 
are defined to allow annotations to be read fully at arm's length 
(javax.lang.model.element.AnnotationMirror, etc.), but that is very 
tedious to program to so as a knowing violation of certainly reflective 
API design principles, a getAnnotation(Class) method is included too:

http://java.sun.com/javase/6/docs/api/javax/lang/model/element/Element.html#getAnnotation(java.lang.Class)

While this method is "inspired by" the getAnnotation method from 
AnnotatedElement, this version of getAnnotation comes with a caveat:

> /Note:/ This method is unlike others in this and related interfaces. 
> It operates on runtime reflective information --- representations of 
> annotation types currently loaded into the VM --- rather than on the 
> representations defined by and used throughout these interfaces. 
> Consequently, calling methods on the returned annotation object can 
> throw many of the exceptions that can be thrown when calling methods 
> on an annotation object returned by core reflection. This method is 
> intended for callers that are written to operate on a known, fixed set 
> of annotation types. 

Dealing with annotation types whose methods are declared to return Class 
objects is problematic in this mixed environment and should be avoided.

Also note that implementing AnnotatedElement implies certain 
implementation restrictions, such as only returning annotation objects 
that are serializable.

-Joe


From mandy.chung at oracle.com  Tue Apr 20 22:54:52 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 20 Apr 2010 22:54:52 -0700
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BCE4B5F.6090509@oracle.com>
References: <4BCE1DBE.6020007@oracle.com> <4BCE4B5F.6090509@oracle.com>
Message-ID: <4BCE932C.9060402@oracle.com>

Hi Joe,

Thanks for the feedback.   I revise the ModuleInfo interface not to 
extend the AnnotatedElement interface but instead just adds the 
isAnnotationPresent and getAnnotation method:
http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html

>
> Dealing with annotation types whose methods are declared to return 
> Class objects is problematic in this mixed environment and should be 
> avoided.

Agree.  I follow the way that the javax.lang.model.Element.getAnnotation 
method specifies so that an exception will be will be thrown when it 
attempts to read a Class object by invoking the relevant method on the 
returned annotation.  I added a new exception 
java.lang.module.UnsupportedElementTypeException for such purpose.

Thanks
Mandy

joe.darcy at oracle.com wrote:
> Hello.
>
> On 4/20/2010 2:33 PM, Mandy Chung wrote:
>> The current API only supports to read annotations of a module when 
>> the module has been installed by using the java.lang.reflect.Module 
>> API (that extends AnnotatedElement).   There are cases that one would 
>> want to read the annotations from module-info while the module is 
>> being installed.  For example, a module can include some annotation 
>> to specify the installation requirement that can be used to determine 
>> if the module installation should continue based on the system 
>> configuration.  It is an opportunity to eliminate  transfers of the 
>> entire module and its dependencies if not needed.
>>
>> We need to provide an API to read the annotations from module-info 
>> but the module may not be installed or downloaded at all.
>>
>> One proposal is to extend java.lang.module.ModuleInfo to extend 
>> AnnotatedElement:
>>
>> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html 
>>
>>
>> It will not load any classes referenced by annotations for this 
>> ModuleInfo until the getAnnotation or other method specified in the 
>> AnnotatedElement interface is called (since those classes might not 
>> exist or be found by the class loader).  In other word, this change 
>> will not affect the current module loading/resolution.   It will use 
>> the current module class loader to find classes to construct the 
>> Annotation objects.   If the type of an annotation's element cannot 
>> be found,  it will result in a TypeNotPresentException in the current 
>> proposed specification.  TypeNotPresentException is an unchecked 
>> exception and perhaps it'd be better to throw a checked exception.
>>
>> Any comment, opinion?
>>
>> Joe, your feedback would be helpful.
>
> Mandy and I spoke about this issue.
>
> In this situation, I recommend using a type other than the core 
> reflection type to model the module, as is already being proposed with 
> ModuleInfo.  Additionally, I recommend that ModuleInfo just implement 
> a selected subset of the methods of AnnotatedElement, say, 
> isAnnotationPresent and getAnnotation, and *not* implement the full 
> interface.
>
> This is part of the approach taken by JSR 269 to address a similar 
> situation of reading annotations from contexts that are not 
> necessarily at runtime after all the relevant classes are loaded.  In 
> JSR 269, types are defined to allow annotations to be read fully at 
> arm's length (javax.lang.model.element.AnnotationMirror, etc.), but 
> that is very tedious to program to so as a knowing violation of 
> certainly reflective API design principles, a getAnnotation(Class) 
> method is included too:
>
> http://java.sun.com/javase/6/docs/api/javax/lang/model/element/Element.html#getAnnotation(java.lang.Class)
>
> While this method is "inspired by" the getAnnotation method from 
> AnnotatedElement, this version of getAnnotation comes with a caveat:
>
>> /Note:/ This method is unlike others in this and related interfaces. 
>> It operates on runtime reflective information --- representations of 
>> annotation types currently loaded into the VM --- rather than on the 
>> representations defined by and used throughout these interfaces. 
>> Consequently, calling methods on the returned annotation object can 
>> throw many of the exceptions that can be thrown when calling methods 
>> on an annotation object returned by core reflection. This method is 
>> intended for callers that are written to operate on a known, fixed 
>> set of annotation types. 
>
> Dealing with annotation types whose methods are declared to return 
> Class objects is problematic in this mixed environment and should be 
> avoided.
>
> Also note that implementing AnnotatedElement implies certain 
> implementation restrictions, such as only returning annotation objects 
> that are serializable.
>
> -Joe



From mr at sun.com  Wed Apr 21 13:55:43 2010
From: mr at sun.com (mr at sun.com)
Date: Wed, 21 Apr 2010 20:55:43 +0000
Subject: hg: jigsaw/jigsaw/jdk: 6 new changesets
Message-ID: <20100421205756.ECAF644648@hg.openjdk.java.net>

Changeset: 9172f93a9b1d
Author:    mr
Date:      2010-01-19 14:45 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9172f93a9b1d

Bind configured modules directly to their libraries

! make/java/java/FILES_java.gmk
! src/share/classes/org/openjdk/jigsaw/BootLoader.java
! src/share/classes/org/openjdk/jigsaw/Context.java
! src/share/classes/org/openjdk/jigsaw/ContextBuilder.java
! src/share/classes/org/openjdk/jigsaw/Library.java
+ src/share/classes/org/openjdk/jigsaw/LibraryPool.java
! src/share/classes/org/openjdk/jigsaw/Linker.java
! src/share/classes/org/openjdk/jigsaw/Loader.java
! src/share/classes/org/openjdk/jigsaw/LoaderPool.java
+ src/share/classes/org/openjdk/jigsaw/LocatableCatalog.java
! src/share/classes/org/openjdk/jigsaw/Resolution.java
! src/share/classes/org/openjdk/jigsaw/Resolver.java
! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! test/org/openjdk/jigsaw/MockLibrary.java
! test/org/openjdk/jigsaw/_Library.java

Changeset: d426dfa33211
Author:    mr
Date:      2010-01-20 14:06 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d426dfa33211

jmod: Improved configuration dumping

! make/java/java/FILES_java.gmk
! src/share/classes/org/openjdk/jigsaw/Configuration.java
! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java
! test/org/openjdk/jigsaw/cli/jmod-basic.sh
! test/org/openjdk/jigsaw/tester.sh

Changeset: 6b0c4feb7552
Author:    mr
Date:      2010-02-19 13:57 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/6b0c4feb7552

Module-file installation

! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java
+ test/org/openjdk/jigsaw/install-files.sh
! test/org/openjdk/jigsaw/tester.sh

Changeset: 1ed96ba7a0c5
Author:    mr
Date:      2010-01-30 11:25 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1ed96ba7a0c5

Module repositories

! make/java/java/FILES_java.gmk
! make/launchers/Makefile
! make/modules/modules.group
! src/share/classes/java/lang/module/Dependence.java
! src/share/classes/org/openjdk/jigsaw/FileConstants.java
+ src/share/classes/org/openjdk/jigsaw/FileHeader.java
+ src/share/classes/org/openjdk/jigsaw/FilePaths.java
! src/share/classes/org/openjdk/jigsaw/Library.java
+ src/share/classes/org/openjdk/jigsaw/PublishedRepository.java
+ src/share/classes/org/openjdk/jigsaw/RemoteRepository.java
+ src/share/classes/org/openjdk/jigsaw/RemoteRepositoryList.java
+ src/share/classes/org/openjdk/jigsaw/Repository.java
+ src/share/classes/org/openjdk/jigsaw/RepositoryCatalog.java
! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! src/share/classes/org/openjdk/jigsaw/cli/Command.java
+ src/share/classes/org/openjdk/jigsaw/cli/Commands.java
! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java
! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
+ src/share/classes/org/openjdk/jigsaw/cli/Repositor.java
! test/org/openjdk/jigsaw/MockLibrary.java
+ test/org/openjdk/jigsaw/TrivialWebServer.java
! test/org/openjdk/jigsaw/_Library.java
+ test/org/openjdk/jigsaw/_PublishedRepository.java
+ test/org/openjdk/jigsaw/_RemoteRepository.java
+ test/org/openjdk/jigsaw/_RemoteRepositoryList.java
+ test/org/openjdk/jigsaw/_RepositoryCatalog.java
! test/org/openjdk/jigsaw/install-files.sh
+ test/org/openjdk/jigsaw/pubrepo.sh
+ test/org/openjdk/jigsaw/remrepo.sh
+ test/org/openjdk/jigsaw/repocat.sh
+ test/org/openjdk/jigsaw/repolist.sh

Changeset: 5a4c4ce24d74
Author:    mr
Date:      2010-02-23 10:16 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5a4c4ce24d74

Installation from module repositories

! src/share/classes/org/openjdk/jigsaw/Configurator.java
! src/share/classes/org/openjdk/jigsaw/ContextBuilder.java
! src/share/classes/org/openjdk/jigsaw/Library.java
! src/share/classes/org/openjdk/jigsaw/PublishedRepository.java
! src/share/classes/org/openjdk/jigsaw/RemoteRepository.java
! src/share/classes/org/openjdk/jigsaw/RemoteRepositoryList.java
! src/share/classes/org/openjdk/jigsaw/Repository.java
! src/share/classes/org/openjdk/jigsaw/RepositoryCatalog.java
! src/share/classes/org/openjdk/jigsaw/Resolution.java
! src/share/classes/org/openjdk/jigsaw/Resolver.java
! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java
+ test/org/openjdk/jigsaw/InstallFromRepo.java
! test/org/openjdk/jigsaw/MockLibrary.java
! test/org/openjdk/jigsaw/_RepositoryCatalog.java
+ test/org/openjdk/jigsaw/install-repo.sh

Changeset: 43ad24ce362e
Author:    mr
Date:      2010-02-25 12:37 -0800
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/43ad24ce362e

Per-module native libraries

! src/share/classes/org/openjdk/jigsaw/Library.java
! src/share/classes/org/openjdk/jigsaw/Loader.java
! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! test/org/openjdk/jigsaw/MockLibrary.java
+ test/org/openjdk/jigsaw/hello-native.sh



From mr at sun.com  Wed Apr 21 13:59:21 2010
From: mr at sun.com (Mark Reinhold)
Date: Wed, 21 Apr 2010 13:59:21 -0700
Subject: Module-file installation, module repositories, and native libraries
Message-ID: <20100421205921.C220B5F4@eggemoggin.niobe.net>

I've just pushed these changes into the Jigsaw forest.

Module-file installation

  The jmod command can now install the module files created by jpkg:

    $ cat src/foo/module-info.java

    module foo @ 1 {
        requires jdk.base;
        class foo.Main;
    }

    $ cat src/foo/foo/Main.java

    package foo;

    public class Main {

        public static void main(String[] args) {
            System.out.println("Foo!");
        }

    }

    $ javac -d classes -modulepath classes \
    > src/foo/module-info.java src/foo/foo/Main.java
    $ jpkg -m classes/foo jmod foo
    $ ls -l foo at 1.jmod
    -rw-r--r-- 1 mr green 691 Apr 21 12:24 foo at 1.jmod
    $ jmod -L mlib create
    $ jmod -L mlib install foo at 1.jmod
    $ jmod -L mlib ls
    foo at 1
    $ java -L mlib -m foo
    Foo!
    $ 

  (The jmod command can still install a module from a regular classes
   directory, as before.)

Module repositories

  A module repository is a collection of modules published on a web
  server.  No special server-side code is required -- a repository is
  just a collection of static files.

  The new jrepo command is provided to create and maintain repositories:

    $ jrepo /var/www/modules create
    $ jrepo /var/www/modules add foo at 1.jmod
    $ jrepo /var/www/modules ls
    foo at 1
    $ 

  A module library can have a list of associated repositories from which
  new modules can be downloaded and installed.  New jmod subcommands are
  provided to manage the repository list and their associated cached
  repository catalogs:

    $ jmod -L mlib create
    $ jmod -L mlib add-repo http://localhost/modules
    $ jmod -L mlib repos
    0 http://localhost/modules/
    $ 

  The -R option to the ls subcommand lists the modules available in a
  library's repositories:

    $ jmod -L mlib ls
    $ jmod -L mlib ls -R
    foo at 1
    $ 

  The install subcommand can now install modules from repositories as
  well as from module files and classes directories.  The -n option
  requests a "dry run", which resolves dependences and calculates
  download and install sizes but doesn't actually install anything:

    $ jmod -L mlib install -n foo
    To install: foo at 1
    627 bytes to download
    610 bytes to store
    $ 

  If you omit the -n option then the requested module(s) and their
  dependences, if any, are installed:

    $ jmod -L mlib install foo
    To install: foo at 1
    627 bytes to download
    610 bytes to store
    $ jmod -L mlib ls
    foo at 1
    $ java -L mlib -m foo
    Foo!
    $ 

Installing modules via the Jigsaw API

  Installing a module and its dependences from a library's repositories
  is a two-step process.  Using the API, you first open the library and
  compute a resolution from an initial ModuleIdQuery:

    import java.lang.module.ModuleSystem;
    import org.openjdk.jigsaw.Library;
    import org.openjdk.jigsaw.SimpleLibrary;
    import org.openjdk.jigsaw.Resolution;

    ModuleSystem ms = ModuleSystem.base();
    Library lib = SimpleLibrary.open(LIB);
    Resolution res
        = lib.resolve(Arrays.asList(ms.parseModuleIdQuery("foo")));

  The Resolution object records, among other things, the list of modules
  to be installed, the number of bytes to be downloaded, and the space
  required to install them:

    out.format("To install: %s%n", res.modulesNeeded());
    out.format("%d bytes to download%n", res.downloadRequired());
    out.format("%d bytes to store%n", res.spaceRequired());

  To proceed with the installation just pass the Resolution object to
  the library's install method:

    lib.install(res);

  After this method returns the requested module will be available
  unless, of course, an exception was thrown.

Native libraries

  Module class loaders now override the findLibrary method, so native
  libraries in a module can be found and linked in the usual way.  See
  the unit test org/openjdk/jigsaw/hello-native.sh for a simple example.

Updated javadoc: http://cr.openjdk.java.net/~mr/jigsaw/api

- Mark


From jonathan.gibbons at oracle.com  Thu Apr 22 04:17:30 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 22 Apr 2010 12:17:30 +0100
Subject: endorsed and extension dirs
Message-ID: <4BD0304A.9060202@oracle.com>

Hi,

Can a JVM expert confirm whether or not endorsed dirs 
(-Djava.endorsed.dirs) and extension dirs (-Djava.ext.dirs) will be 
continue to be supported in JVM legacy mode in JDK7/Jigsaw?

-- Jon


From mandy.chung at oracle.com  Thu Apr 22 07:15:57 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 22 Apr 2010 07:15:57 -0700
Subject: endorsed and extension dirs
In-Reply-To: <4BD0304A.9060202@oracle.com>
References: <4BD0304A.9060202@oracle.com>
Message-ID: <4BD05A1D.50102@oracle.com>

Jonathan Gibbons wrote:
> Hi,
>
> Can a JVM expert confirm whether or not endorsed dirs 
> (-Djava.endorsed.dirs) and extension dirs (-Djava.ext.dirs) will be 
> continue to be supported in JVM legacy mode in JDK7/Jigsaw?
>

Existing features should continue to work in JVM legacy mode.  Do you 
find any issue with the endorsed standard mechanism and extension dirs?  
If so, it's a regression.

Mandy



From jonathan.gibbons at oracle.com  Thu Apr 22 07:27:02 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 22 Apr 2010 15:27:02 +0100
Subject: endorsed and extension dirs
In-Reply-To: <4BD05A1D.50102@oracle.com>
References: <4BD0304A.9060202@oracle.com> <4BD05A1D.50102@oracle.com>
Message-ID: <4BD05CB6.1080105@oracle.com>

Mandy Chung wrote:
> Jonathan Gibbons wrote:
>> Hi,
>>
>> Can a JVM expert confirm whether or not endorsed dirs 
>> (-Djava.endorsed.dirs) and extension dirs (-Djava.ext.dirs) will be 
>> continue to be supported in JVM legacy mode in JDK7/Jigsaw?
>>
>
> Existing features should continue to work in JVM legacy mode.  Do you 
> find any issue with the endorsed standard mechanism and extension 
> dirs?  If so, it's a regression.
>
> Mandy
>


No, I was just checking, since I'm adding support for these in javac in 
order to get existing tests to pass.  These tests verify similar 
semantics for these options for java and javac.

-- Jon


From mr at sun.com  Thu Apr 22 11:34:41 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:34:41 +0000
Subject: hg: jigsaw/jigsaw: Added tag jigsaw-b03 for changeset bef3965ce4a8
Message-ID: <20100422183441.942B544665@hg.openjdk.java.net>

Changeset: 696214fdbb70
Author:    mr
Date:      2010-04-22 11:31 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/rev/696214fdbb70

Added tag jigsaw-b03 for changeset bef3965ce4a8

! .hgtags



From mr at sun.com  Thu Apr 22 11:34:45 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:34:45 +0000
Subject: hg: jigsaw/jigsaw/corba: Added tag jigsaw-b03 for changeset
	4a3fb3218e31
Message-ID: <20100422183447.9D80F44666@hg.openjdk.java.net>

Changeset: 8a1a380a9a43
Author:    mr
Date:      2010-04-22 11:31 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/8a1a380a9a43

Added tag jigsaw-b03 for changeset 4a3fb3218e31

! .hgtags



From mr at sun.com  Thu Apr 22 11:34:52 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:34:52 +0000
Subject: hg: jigsaw/jigsaw/hotspot: Added tag jigsaw-b03 for changeset
	f59c81b1afe9
Message-ID: <20100422183458.C311E44667@hg.openjdk.java.net>

Changeset: c4854f8d4afe
Author:    mr
Date:      2010-04-22 11:31 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c4854f8d4afe

Added tag jigsaw-b03 for changeset f59c81b1afe9

! .hgtags



From mr at sun.com  Thu Apr 22 11:35:04 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:35:04 +0000
Subject: hg: jigsaw/jigsaw/jaxp: Added tag jigsaw-b03 for changeset
	a45dbf8ee934
Message-ID: <20100422183504.8E9E344668@hg.openjdk.java.net>

Changeset: d5dbf8dc7968
Author:    mr
Date:      2010-04-22 11:31 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/d5dbf8dc7968

Added tag jigsaw-b03 for changeset a45dbf8ee934

! .hgtags



From mr at sun.com  Thu Apr 22 11:35:08 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:35:08 +0000
Subject: hg: jigsaw/jigsaw/jaxws: Added tag jigsaw-b03 for changeset
	5b453e0d76e4
Message-ID: <20100422183508.7B25844669@hg.openjdk.java.net>

Changeset: fe9f79764b88
Author:    mr
Date:      2010-04-22 11:31 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/fe9f79764b88

Added tag jigsaw-b03 for changeset 5b453e0d76e4

! .hgtags



From mr at sun.com  Thu Apr 22 11:35:13 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:35:13 +0000
Subject: hg: jigsaw/jigsaw/jdk: Added tag jigsaw-b03 for changeset 43ad24ce362e
Message-ID: <20100422183538.A54594466A@hg.openjdk.java.net>

Changeset: c1c7ce0bd91e
Author:    mr
Date:      2010-04-22 11:32 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c1c7ce0bd91e

Added tag jigsaw-b03 for changeset 43ad24ce362e

! .hgtags



From mr at sun.com  Thu Apr 22 11:35:46 2010
From: mr at sun.com (mr at sun.com)
Date: Thu, 22 Apr 2010 18:35:46 +0000
Subject: hg: jigsaw/jigsaw/langtools: Added tag jigsaw-b03 for changeset
	e2879c758bac
Message-ID: <20100422183551.14D944466B@hg.openjdk.java.net>

Changeset: ff48ee04db4c
Author:    mr
Date:      2010-04-22 11:31 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ff48ee04db4c

Added tag jigsaw-b03 for changeset e2879c758bac

! .hgtags



From Alan.Bateman at Sun.COM  Thu Apr 22 13:42:55 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 22 Apr 2010 21:42:55 +0100
Subject: Module-file installation, module repositories,
	and native libraries
In-Reply-To: <20100421205921.C220B5F4@eggemoggin.niobe.net>
References: <20100421205921.C220B5F4@eggemoggin.niobe.net>
Message-ID: <4BD0B4CF.3030106@sun.com>

Mark Reinhold wrote:
> :
>
> Native libraries
>
>   Module class loaders now override the findLibrary method, so native
>   libraries in a module can be found and linked in the usual way.  See
>   the unit test org/openjdk/jigsaw/hello-native.sh for a simple example.
>   
Nice! I'm curious about "platform" modules. If we packaged up as a jmod 
package, and installed into the system module library then should jmod 
special case the installation of the native libs (or binaries) and 
install them into the image's lib or bin directory than the module 
library? I'm just wonder if we are re-organizing the platform's native 
libraries.

-Alan.


From joe.darcy at oracle.com  Thu Apr 22 16:50:07 2010
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 22 Apr 2010 16:50:07 -0700
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BCE932C.9060402@oracle.com>
References: <4BCE1DBE.6020007@oracle.com> <4BCE4B5F.6090509@oracle.com>
	<4BCE932C.9060402@oracle.com>
Message-ID: <4BD0E0AF.1040905@oracle.com>



On 4/20/2010 10:54 PM, Mandy Chung wrote:
> Hi Joe,
>
> Thanks for the feedback.   I revise the ModuleInfo interface not to 
> extend the AnnotatedElement interface but instead just adds the 
> isAnnotationPresent and getAnnotation method:
> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html
>
>>
>> Dealing with annotation types whose methods are declared to return 
>> Class objects is problematic in this mixed environment and should be 
>> avoided.
>
> Agree.  I follow the way that the 
> javax.lang.model.Element.getAnnotation method specifies so that an 
> exception will be will be thrown when it attempts to read a Class 
> object by invoking the relevant method on the returned annotation.  I 
> added a new exception java.lang.module.UnsupportedElementTypeException 
> for such purpose.
>

Looks fine.

-Joe


From mr at sun.com  Fri Apr 23 11:41:17 2010
From: mr at sun.com (Mark Reinhold)
Date: Fri, 23 Apr 2010 11:41:17 -0700
Subject: Module-file installation, module repositories,
	and native libraries 
In-Reply-To: alan.bateman@sun.com; Thu, 22 Apr 2010 21:42:55 BST;
	<4BD0B4CF.3030106@sun.com> 
Message-ID: <20100423184117.7F8534B7@eggemoggin.niobe.net>

> Date: Thu, 22 Apr 2010 21:42:55 +0100
> From: alan.bateman at sun.com

> Mark Reinhold wrote:
>> :
>> 
>> Native libraries
>> 
>>   Module class loaders now override the findLibrary method, so native
>>   libraries in a module can be found and linked in the usual way.  See
>>   the unit test org/openjdk/jigsaw/hello-native.sh for a simple example.
>> 
> Nice! I'm curious about "platform" modules. If we packaged up as a jmod
> package, and installed into the system module library then should jmod special
> case the installation of the native libs (or binaries) and install them into
> the image's lib or bin directory than the module library? I'm just wonder if we
> are re-organizing the platform's native libraries.

We will reorganize the platform's native libraries, but we'll likely need
to special-case some files, especially on Windows.

- Mark


From jonathan.gibbons at oracle.com  Mon Apr 26 10:17:14 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 26 Apr 2010 18:17:14 +0100
Subject: changes to org.openjdk.jigsaw.Library
Message-ID: <4BD5CA9A.3040201@oracle.com>

Mark,

Are there notes anywhere on the changes to org.openjdk.jigsaw.Library ?

There used to be a method called listClasses; that no longer seems to 
exist, and the replacement seems to be listLocalClasses. However, this 
method seems to have different semantics -- it returns null, where the 
old method did not, and some of the javac regression tests are now 
having trouble locating java.lang, so it would seem the behavior is 
different as well.

-- Jon


From Alan.Bateman at oracle.com  Tue Apr 27 04:12:13 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Apr 2010 12:12:13 +0100
Subject: jmod request
In-Reply-To: <4BCDC4C7.8090207@oracle.com>
References: <4BCDC4C7.8090207@oracle.com>
Message-ID: <4BD6C68D.1040303@oracle.com>

Jonathan Gibbons wrote:
> It seems that if a module has been installed, it cannot be replaced by 
> installing it again.
>
> Is there any chance of getting "remove" or "uninstall" options for 
> jmod, or even the ability to reinstall a module.  Now that we can 
> build all the modules for JDK, it would be very helpful to be able to 
> install new modules without rebuilding JDK.
>
> As a short term work around, it appears to work to delete the 
> appropriate directory with an "rm" command.   Is this likely OK, or 
> likely to cause horrors in the minds of the folk that understand 
> module libraries?
>
> -- Jon
Mark - is uninstall feasible? I assume there is potential for 
consistency issues if there is library delegation and a module is 
removed from a parent library. Also, I wonder about the consequences of 
uninstalling a module when the library is in use by a running application.

-Alan.



From tmarble at info9.net  Tue Apr 27 07:16:57 2010
From: tmarble at info9.net (Tom Marble)
Date: Tue, 27 Apr 2010 09:16:57 -0500
Subject: jmod request
In-Reply-To: <4BD6C68D.1040303@oracle.com>
References: <4BCDC4C7.8090207@oracle.com> <4BD6C68D.1040303@oracle.com>
Message-ID: <z2oddde51ab1004270716zae7935dcsa8664bbce0bd67dd@mail.gmail.com>

On Tue, Apr 27, 2010 at 6:12 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> Mark - is uninstall feasible? I assume there is potential for consistency
> issues if there is library delegation and a module is removed from a parent
> library. Also, I wonder about the consequences of uninstalling a module when
> the library is in use by a running application.

It seems that jmod wants to be able to handle install and uninstall
(gracefully).
We really don't want to repeat the problem like the Windows Registry which
simply gets corrupted over time and results in the need to regularly
reinstall the OS.

We may be able to get some inspiration from how Debian manages
package installation (and removal) with apt-get [0].  Specifically there are
commands which:

  'remove' will remove a package (and and any packages which
  depend on it), but some configuration information
  will remain for the package (e.g. files in /etc/ ).

  The is a 'purge' command which will remove everything
  for a package (including configuration files).

  There is a '--force-yes' option (highly discouraged) to cause
  the operation (e.g. 'remove') to continue despite violating
  package interdependencies -- this would be equivalent to the
  'rm -r module-directory' approach.

  normally 'install' will refuse to reinstall a package if it is
  already at the same version of the proposed new package.
  However, one can specify '--reinstall' to reinstall even if
  the package is at the newest version.

Note that there are various front ends to Apt which can prompt the
user to interactively resolve dependency problems or automate
installation, etc. [1]  The flow of operations is described here [2] which
leverages install hook scripts [3].

Debian (and UNIX systems generally) have the facility to
upgrade running programs [4].  This speaks to the need for a convention
for start/stop scripts (*a la* Sys V [5]) for Java programs (daemons).
 This is likely
beyond the scope of Jigsaw itself, but does suggest how hooks in Jigsaw
could allow Java programs to gracefully handle lifecycle management with
the native packaging system.  Removing packages for running programs
may not cause them to abort as their binaries and libraries may trivially
be in the filesystem cache, but clearly expectations about polite behavior
in such circumstances should be modest.  We don't need to assume
that a Jigsaw administrator would have higher expectations.

Regards,

--Tom

[0] apt-get man page (slightly out of date, purge is now a command
    not a --purge qualifier)
    http://linux.die.net/man/8/apt-get
[1] Apt front ends (e.g. that allow interactively resolving dependency problems)
    http://wiki.debian.org/Apt
[2] Apt event flow
    http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_the_event_flow_of_the_package_management
[3] {post|pre}{inst|rm} files
    http://www.debian.org/doc/manuals/maint-guide/ch-dother.en.html#s-maintscripts
[4] Update running program
    http://www.debian.org/doc/FAQ/ch-pkgtools.en.html#s-updaterunning
[5] start/stop scripts
   http://en.wikipedia.org/wiki/Init


From mandy.chung at oracle.com  Tue Apr 27 23:19:49 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 27 Apr 2010 23:19:49 -0700
Subject: Please review the change to access the annotations from module-info
Message-ID: <4BD7D385.4030602@oracle.com>

Joe,

Thanks for the feedback to the ModuleInfo API.  This change also 
implements the reflection methods to access the annotations in the 
java.lang.reflect.Module class (i.e. implementation of AnnotatedElement 
methods).

The webrev is at:
   http://cr.openjdk.java.net/~mchung/jigsaw/annotations/webrev/

Most of the work is done in the java.lang.module.ModuleInfoAnnotation 
class that does the following:
- parses a raw annotation from the module-info.class
- stores the element value pairs
- creates an Annotation object using the core reflection
- it supports for both ModuleInfo and Module API to access annotations.  
The Annotation objects created for the ModuleInfo.getAnnotation() method 
doesn't support elements of Class type.

I added a constructor of CoreReflectionFactory to take a Module 
parameter so that its module class loader will be used to load classes 
when instantiating an Annotation object.   Is there any issue with 
that?  The factory will only be used to parse class signatures.

Thanks
Mandy


From mr at sun.com  Wed Apr 28 10:12:11 2010
From: mr at sun.com (Mark Reinhold)
Date: Wed, 28 Apr 2010 10:12:11 -0700
Subject: changes to org.openjdk.jigsaw.Library 
In-Reply-To: jonathan.gibbons@oracle.com; Mon, 26 Apr 2010 18:17:14 BST;
	<4BD5CA9A.3040201@oracle.com> 
Message-ID: <20100428171211.AE71B481@eggemoggin.niobe.net>

> Date: Mon, 26 Apr 2010 18:17:14 +0100
> From: jonathan.gibbons at oracle.com

> Are there notes anywhere on the changes to org.openjdk.jigsaw.Library ?

Nope.

> There used to be a method called listClasses; that no longer seems to exist,
> and the replacement seems to be listLocalClasses. However, this method seems to
> have different semantics -- it returns null, where the old method did not, and
> some of the javac regression tests are now having trouble locating java.lang,
> so it would seem the behavior is different as well.

Yes, the behavior is different: listLocalClasses doesn't look for the
requested module in any parent libraries, which is probably why you can't
find java.lang.

I removed the listClasses method while cleaning up the parent-delegation
logic in changeset 9172f93a9b1d.  Sorry about that -- I wasn't aware you
were using it, and based upon our past discussions about javac internals
I assumed that you wouldn't need it.

It's easy enough to add back in -- shall I do that?

- Mark


From jonathan.gibbons at oracle.com  Wed Apr 28 11:07:24 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Apr 2010 19:07:24 +0100
Subject: changes to org.openjdk.jigsaw.Library
In-Reply-To: <20100428171211.AE71B481@eggemoggin.niobe.net>
References: <20100428171211.AE71B481@eggemoggin.niobe.net>
Message-ID: <4BD8795C.1090401@oracle.com>

Mark Reinhold wrote:
>> Date: Mon, 26 Apr 2010 18:17:14 +0100
>> From: jonathan.gibbons at oracle.com
>>     
>
>   
>> Are there notes anywhere on the changes to org.openjdk.jigsaw.Library ?
>>     
>
> Nope.
>
>   
>> There used to be a method called listClasses; that no longer seems to exist,
>> and the replacement seems to be listLocalClasses. However, this method seems to
>> have different semantics -- it returns null, where the old method did not, and
>> some of the javac regression tests are now having trouble locating java.lang,
>> so it would seem the behavior is different as well.
>>     
>
> Yes, the behavior is different: listLocalClasses doesn't look for the
> requested module in any parent libraries, which is probably why you can't
> find java.lang.
>
> I removed the listClasses method while cleaning up the parent-delegation
> logic in changeset 9172f93a9b1d.  Sorry about that -- I wasn't aware you
> were using it, and based upon our past discussions about javac internals
> I assumed that you wouldn't need it.
>
> It's easy enough to add back in -- shall I do that?
>
> - Mark
>   
javac needs some form of list mechanism to be able to determine the 
contents of a package (e.g. import on demand).  I've converted to using 
listLocalClasses, and that fixed one of my two test failures.   I'm 
still investigating the other failure.  Let me find the root cause there 
before asking you to restore listClasses.

-- Jon


From jonathan.gibbons at sun.com  Wed Apr 28 11:45:27 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 28 Apr 2010 18:45:27 +0000
Subject: hg: jigsaw/jigsaw/langtools: fix annotation support
Message-ID: <20100428184529.375F24421D@hg.openjdk.java.net>

Changeset: 2e77b8ab836d
Author:    jjg
Date:      2010-04-28 11:44 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/2e77b8ab836d

fix annotation support

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/modules/ModuleAnnotsTest01.java



From Roger.Riggs at oracle.com  Wed Apr 28 11:50:58 2010
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 28 Apr 2010 14:50:58 -0400
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BCE932C.9060402@oracle.com>
References: <4BCE1DBE.6020007@oracle.com> <4BCE4B5F.6090509@oracle.com>
	<4BCE932C.9060402@oracle.com>
Message-ID: <4BD88392.6080903@Oracle.com>

Hi,

Some comments on the module APIs:

    * On ModuleInfo, I would like to see an enumeration of the Annotations;
      like getAnnotations() on Module.  This will allow the caller to
      iterate over
      the available annotations without having to make a call to probe
      for each one.
    * Style: Should there be more symmetry between Module and ModuleInfo
      APIs?
      ModuleInfo returns Set<x>, while Module returns Annotation[] arrays.
      Use of arrays generally requires that they be copied; creating
      garbage.
    * In the ModuleInfo.permits() method it returns a Set<String>;
      in contrast the provides() method returns a Set<ModuleId>. 
      Is there a reason that String is used instead of a ModuleId?
    * Are the sets returned from permits(), requires(), provides()
      modifiable by
      the caller?  It would be good to be clear about whether they are
      copies
      of the internal structures or are read-only to prevent corruption.
      Read-only would
      be better and create less garbage.
    * In the case of annotations whose values are classes (see the
      getAnnotation method),
      and the UnsupportedElementTypeException is thrown, under what
      circumstances
      will the getClassNames() method return more than one Class name? 
      A List<String> seems a bit heavyweight for this purpose.
    * In the AnnotatedElement interface the TypeNotPresentException is
      specified
      to be thrown when the class is not accessible.  Should it be used
      in ModuleInfo.getAnnotation
      instead of the new UnsupportedElementTypeException?  BTW, this
      name is not quite correct since
      the type is just not found in the caller's type system.

Roger



Mandy Chung wrote:
> Hi Joe,
>
> Thanks for the feedback.   I revised the ModuleInfo interface not to 
> extend the AnnotatedElement interface but instead just adds the 
> isAnnotationPresent and getAnnotation method:
> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html 
>
>
>>
>> Dealing with annotation types whose methods are declared to return 
>> Class objects is problematic in this mixed environment and should be 
>> avoided.
>
> Agree.  I follow the way that the 
> javax.lang.model.Element.getAnnotation method specifies so that an 
> exception will be will be thrown when it attempts to read a Class 
> object by invoking the relevant method on the returned annotation.  I 
> added a new exception java.lang.module.UnsupportedElementTypeException 
> for such purpose.
>
> Thanks
> Mandy
>
> joe.darcy at oracle.com wrote:
>> Hello.
>>
>> On 4/20/2010 2:33 PM, Mandy Chung wrote:
>>> The current API only supports to read annotations of a module when 
>>> the module has been installed by using the java.lang.reflect.Module 
>>> API (that extends AnnotatedElement).   There are cases that one 
>>> would want to read the annotations from module-info while the module 
>>> is being installed.  For example, a module can include some 
>>> annotation to specify the installation requirement that can be used 
>>> to determine if the module installation should continue based on the 
>>> system configuration.  It is an opportunity to eliminate  transfers 
>>> of the entire module and its dependencies if not needed.
>>>
>>> We need to provide an API to read the annotations from module-info 
>>> but the module may not be installed or downloaded at all.
>>>
>>> One proposal is to extend java.lang.module.ModuleInfo to extend 
>>> AnnotatedElement:
>>>
>>> http://cr.openjdk.java.net/~mchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html 
>>>
>>>
>>> It will not load any classes referenced by annotations for this 
>>> ModuleInfo until the getAnnotation or other method specified in the 
>>> AnnotatedElement interface is called (since those classes might not 
>>> exist or be found by the class loader).  In other word, this change 
>>> will not affect the current module loading/resolution.   It will use 
>>> the current module class loader to find classes to construct the 
>>> Annotation objects.   If the type of an annotation's element cannot 
>>> be found,  it will result in a TypeNotPresentException in the 
>>> current proposed specification.  TypeNotPresentException is an 
>>> unchecked exception and perhaps it'd be better to throw a checked 
>>> exception.
>>>
>>> Any comment, opinion?
>>>
>>> Joe, your feedback would be helpful.



From mandy.chung at oracle.com  Wed Apr 28 12:22:33 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 28 Apr 2010 12:22:33 -0700
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BD88392.6080903@Oracle.com>
References: <4BCE1DBE.6020007@oracle.com>
	<4BCE4B5F.6090509@oracle.com>	<4BCE932C.9060402@oracle.com>
	<4BD88392.6080903@Oracle.com>
Message-ID: <4BD88AF9.2050702@oracle.com>

Hi Roger,

Thanks for the comments:

Roger Riggs wrote:
> Hi,
>
> Some comments on the module APIs:
>
>    * On ModuleInfo, I would like to see an enumeration of the 
> Annotations;
>      like getAnnotations() on Module.  This will allow the caller to
>      iterate over
>      the available annotations without having to make a call to probe
>      for each one.

The caller knows which annotations to look for.  You should use the 
isAnnotationPresent() method to check.  What's the use case to enumerate 
all Annotations?  What happens if a type doesn't exist?  The caller will 
need to catch the exception if an annotation type is not found.  In that 
case, what would the caller do?

>    * Style: Should there be more symmetry between Module and ModuleInfo
>      APIs?
>      ModuleInfo returns Set<x>, while Module returns Annotation[] arrays.
>      Use of arrays generally requires that they be copied; creating
>      garbage.

Joe can help explain the reason why AnnotatedElement.getAnnotations() 
returns Annotation[].

>    * In the ModuleInfo.permits() method it returns a Set<String>;
>      in contrast the provides() method returns a Set<ModuleId>.      
> Is there a reason that String is used instead of a ModuleId?
>    * Are the sets returned from permits(), requires(), provides()
>      modifiable by
>      the caller?  
unmodifiable.  Will make it clear in the spec.
> It would be good to be clear about whether they are
>      copies
>      of the internal structures or are read-only to prevent corruption.
>      Read-only would
>      be better and create less garbage.
>    * In the case of annotations whose values are classes (see the
>      getAnnotation method),
>      and the UnsupportedElementTypeException is thrown, under what
>      circumstances
>      will the getClassNames() method return more than one Class name? 
>      

Class[]

> A List<String> seems a bit heavyweight for this purpose.

Why would you think it's heavyweight?  What performance concern do you have?

>    * In the AnnotatedElement interface the TypeNotPresentException is
>      specified
>      to be thrown when the class is not accessible.  Should it be used
>      in ModuleInfo.getAnnotation
>      instead of the new UnsupportedElementTypeException?  BTW, this
>      name is not quite correct since
>      the type is just not found in the caller's type system.

Suggestion on a better name is welcome.

As specified in the UnsupportedElementTypeException spec:
UnsupportedElementTypeException is thrown when an application attempts 
to read a |Class| object or a Class[]-valued element by invoking the 
relevant method on an annotation returned by the 
|ModuleInfo.getAnnotation(java.lang.Class| 
<http://cr.openjdk.java.net/%7Emchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html#getAnnotation%28java.lang.Class%29>) 
method. 

The class could be found but access to elements of type Class object and 
Class[] is just not supported since the information necessary to locate 
and load a class is not available when the module is not installed. 
TypeNotPresentException is not appropriate for this case.  

Thanks
Mandy


From mr at sun.com  Wed Apr 28 12:37:38 2010
From: mr at sun.com (Mark Reinhold)
Date: Wed, 28 Apr 2010 12:37:38 -0700
Subject: ModuleInfo extends AnnotatedElement 
In-Reply-To: mandy.chung@oracle.com; Wed, 28 Apr 2010 12:22:33 PDT;
	<4BD88AF9.2050702@oracle.com> 
Message-ID: <20100428193738.24772481@eggemoggin.niobe.net>

> Date: Wed, 28 Apr 2010 12:22:33 -0700
> From: mandy.chung at oracle.com

> Roger Riggs wrote:
>> ...
>>    * In the ModuleInfo.permits() method it returns a Set<String>;
>>      in contrast the provides() method returns a Set<ModuleId>. Is there
>>      a reason that String is used instead of a ModuleId?

Yes.  Virtual modules don't have version numbers.

- Mark


From Roger.Riggs at oracle.com  Wed Apr 28 12:49:15 2010
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 28 Apr 2010 15:49:15 -0400
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BD88AF9.2050702@oracle.com>
References: <4BCE1DBE.6020007@oracle.com>
	<4BCE4B5F.6090509@oracle.com>	<4BCE932C.9060402@oracle.com>
	<4BD88392.6080903@Oracle.com> <4BD88AF9.2050702@oracle.com>
Message-ID: <4BD8913B.3050904@Oracle.com>

Hi Mandy,


Mandy Chung wrote:
> Hi Roger,
>
> Thanks for the comments:
>
> Roger Riggs wrote:
>> Hi,
>>
>> Some comments on the module APIs:
>>
>>    * On ModuleInfo, I would like to see an enumeration of the 
>> Annotations;
>>      like getAnnotations() on Module.  This will allow the caller to
>>      iterate over
>>      the available annotations without having to make a call to probe
>>      for each one.
>
> The caller knows which annotations to look for.  You should use the 
> isAnnotationPresent() method to check.  What's the use case to 
> enumerate all Annotations?  What happens if a type doesn't exist?  The 
> caller will need to catch the exception if an annotation type is not 
> found.  In that case, what would the caller do?
The difference is in the coding style, the current API suggests/requires:

        // This pattern always causes 5 calls and perhaps 5 linear searches for the annotation
	ModuleInfo m = xxx;

        Annotation1 a1 = m.getAnnotation(Annotation1.class);
	if (a1 != null) {...}
        Annotation2 a2 = m.getAnnotation(Annotation2.class);
	if (a1 != null) {...}
        Annotation1 a3 = m.getAnnotation(Annotation3.class);
	if (a1 != null) {...}
        Annotation1 a4 = m.getAnnotation(Annotation4.class);
	if (a1 != null) {...}
        Annotation1 a5 = m.getAnnotation(Annotation5.class);
	if (a1 != null) {...}

vs.
	// This pattern touches each annotation that is present only once.
	ModuleInfo m = xxx;
	for (Annotation a : m.getAnnotations) {
	    if (a instanceof Annotation1) {
        	Annotation1 a1 = (Annotation1)a;
	    }
	    if (a instanceof Annotation2) {
        	Annotation2 a2 = (Annotation2)a;
	    }
	    if (a instanceof Annotation3) {
        	Annotation3 a3 = (Annotation3)a;
	    }
	    if (a instanceof Annotation4) {
        	Annotation4 a4 = (Annotation4)a;
	    }
	    if (a instanceof Annotation5) {
        	Annotation5 a5 = (Annotation1)a;
	    }
	}



Furthermore, if you want to write a tool the prints out the annotations 
that are present
it can be done conveniently.

Pretty much every other API that maintains a set of something provides 
an iterator;
ModuleInfo should too.

>>    * In the ModuleInfo.permits() method it returns a Set<String>;
>>      in contrast the provides() method returns a Set<ModuleId>.      

>> Is there a reason that String is used instead of a ModuleId?
??
>
>>
>>    * In the case of annotations whose values are classes (see the
>>      getAnnotation method),
>>      and the UnsupportedElementTypeException is thrown, under what
>>      circumstances
>>      will the getClassNames() method return more than one Class name? 
>>      
>
> Class[]
Ok, so it will just list the classes that are not available.
>
>> A List<String> seems a bit heavyweight for this purpose.
>
> Why would you think it's heavyweight?  What performance concern do you 
> have?
Sorry, I've been working on targets where space and time always matter.
If you don't create garbage, you don't have to clean it up.
>
>>    * In the AnnotatedElement interface the TypeNotPresentException is 
>> specified
>>      to be thrown when the class is not accessible.  Should it be used
>>      in ModuleInfo.getAnnotation
>>      instead of the new UnsupportedElementTypeException?  BTW, this
>>      name is not quite correct since
>>      the type is just not found in the caller's type system.
>
> Suggestion on a better name is welcome.
ClassNotFoundException; NoClassDefFoundException...

TypeNotPresentException

These are all failures because Class.forName fails because it cannot 
find the class.

>
> As specified in the UnsupportedElementTypeException spec:
> UnsupportedElementTypeException is thrown when an application attempts 
> to read a |Class| object or a Class[]-valued element by invoking the 
> relevant method on an annotation returned by the 
> |ModuleInfo.getAnnotation(java.lang.Class| 
> <http://cr.openjdk.java.net/%7Emchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html#getAnnotation%28java.lang.Class%29>) 
> method.
> The class could be found but access to elements of type Class object 
> and Class[] is just not supported since the information necessary to 
> locate and load a class is not available when the module is not 
> installed. TypeNotPresentException is not appropriate for this case. 
I understand there is no attempt to locate or define the class *in* the 
module being inspected
because the module is not fully defined and no classloader can be 
created for it.

But the class name(s) found in the annotations *are* being resolved using
the caller's classloader (Class.forName() or equivalent).  If the 
annotation class is not found
then that is the failure that is being reported, and that is very 
similar to ClassNotFoundException
or TypeNotPresentException.


Roger


From Roger.Riggs at oracle.com  Wed Apr 28 12:53:19 2010
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 28 Apr 2010 15:53:19 -0400
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <20100428193738.24772481@eggemoggin.niobe.net>
References: <20100428193738.24772481@eggemoggin.niobe.net>
Message-ID: <4BD8922F.4030806@Oracle.com>

Thanks, Mark,

Where can I find the history on the lack of version numbers in virtual 
modules.

I would think that even when using a virtual module the version number 
would matter.
Or that providing a virtual module would mean providing a particular 
version of that module.
I guess I'm missing some background.

Roger


Mark Reinhold wrote:
>> Date: Wed, 28 Apr 2010 12:22:33 -0700
>> From: mandy.chung at oracle.com
>>     
>
>   
>> Roger Riggs wrote:
>>     
>>> ...
>>>    * In the ModuleInfo.permits() method it returns a Set<String>;
>>>      in contrast the provides() method returns a Set<ModuleId>. Is there
>>>      a reason that String is used instead of a ModuleId?
>>>       
>
> Yes.  Virtual modules don't have version numbers.
>
> - Mark
>   



From dalibor.topic at sun.com  Wed Apr 28 13:06:28 2010
From: dalibor.topic at sun.com (dalibor.topic at sun.com)
Date: Wed, 28 Apr 2010 20:06:28 +0000
Subject: hg: jigsaw/jigsaw/jdk: Don't call System.exit outside main
Message-ID: <20100428200653.B7EA644224@hg.openjdk.java.net>

Changeset: 741f19e29ea0
Author:    robilad
Date:      2010-04-26 15:21 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/741f19e29ea0

Don't call System.exit outside main

! src/share/classes/org/openjdk/jigsaw/cli/Packager.java



From mr at sun.com  Wed Apr 28 13:21:44 2010
From: mr at sun.com (Mark Reinhold)
Date: Wed, 28 Apr 2010 13:21:44 -0700
Subject: jmod request 
In-Reply-To: alan.bateman@oracle.com; Tue, 27 Apr 2010 12:12:13 BST;
	<4BD6C68D.1040303@oracle.com> 
Message-ID: <20100428202144.0A581481@eggemoggin.niobe.net>

> Date: Tue, 27 Apr 2010 12:12:13 +0100
> From: alan.bateman at oracle.com

> Jonathan Gibbons wrote:
>> It seems that if a module has been installed, it cannot be replaced by
>> installing it again.
>> 
>> Is there any chance of getting "remove" or "uninstall" options for jmod, or
>> even the ability to reinstall a module.  Now that we can build all the
>> modules for JDK, it would be very helpful to be able to install new modules
>> without rebuilding JDK.
>> 
>> As a short term work around, it appears to work to delete the appropriate
>> directory with an "rm" command.   Is this likely OK, or likely to cause
>> horrors in the minds of the folk that understand module libraries?
> 
> Mark - is uninstall feasible? I assume there is potential for consistency
> issues if there is library delegation and a module is removed from a parent
> library.

Yes.  I don't know how to prevent such inconsistencies without making
a library aware of all of its children, which seems undesirable (anyone
remember Codemgr_wsdata/children?).

If we can't prevent inconsistencies then we can at least detect and offer
to repair them.  One possibility would be for a library to store the
last-modified time of its parent.  If, at startup, the parent has been
modified then validate the library, and if any required modules are
missing but available from a repository, then offer to install them.

This check must be done recursively, but library delegation chains are
expected to be short.

>          Also, I wonder about the consequences of uninstalling a module when
> the library is in use by a running application.

The easy solution is simply to disallow that, by arranging for running
applications to hold read locks on the modules that they use.  That's not
very friendly, though, so we'll have to explore other solutions such as,
e.g., marking in-use modules for future deletion.

- Mark


From joe.darcy at oracle.com  Wed Apr 28 13:31:48 2010
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 28 Apr 2010 13:31:48 -0700
Subject: Please review the change to access the annotations from
	module-info
In-Reply-To: <4BD7D385.4030602@oracle.com>
References: <4BD7D385.4030602@oracle.com>
Message-ID: <4BD89B34.1070708@oracle.com>

Hello.

Mandy Chung wrote:
> Joe,
>
> Thanks for the feedback to the ModuleInfo API.  This change also 
> implements the reflection methods to access the annotations in the 
> java.lang.reflect.Module class (i.e. implementation of 
> AnnotatedElement methods).
>
> The webrev is at:
>   http://cr.openjdk.java.net/~mchung/jigsaw/annotations/webrev/
>
> Most of the work is done in the java.lang.module.ModuleInfoAnnotation 
> class that does the following:
> - parses a raw annotation from the module-info.class
> - stores the element value pairs
> - creates an Annotation object using the core reflection
> - it supports for both ModuleInfo and Module API to access 
> annotations.  The Annotation objects created for the 
> ModuleInfo.getAnnotation() method doesn't support elements of Class type.
>
> I added a constructor of CoreReflectionFactory to take a Module 
> parameter so that its module class loader will be used to load classes 
> when instantiating an Annotation object.   Is there any issue with 
> that?  The factory will only be used to parse class signatures.


Some comments from a first pass over the code:

In ModuleInfo.java, I recommend adding an "@see 
java.lang.reflect.AnnotatedElement#isAnnotationPresent" to the 
isAnnotationPresent method.

In ModuleInfoReader.java, if you want to start using some new language 
features, the following line is an ideal candidate for the diamond operator:

70     private Map<String, ModuleInfoAnnotation> annotationTypes = new 
LinkedHashMap<String, ModuleInfoAnnotation>();

With diamond

70     private Map<String, ModuleInfoAnnotation> annotationTypes = new 
LinkedHashMap<>();

Later in that file, this looks like a candidate for strings in switch:

 135             if (name.equals(MODULE))
 136                 readModule();
 137             else if (name.equals(MODULE_PROVIDES))
 138                 readModuleProvides();
 139             else if (name.equals(MODULE_REQUIRES))
 140                 readModuleRequires();
 141             else if (name.equals(MODULE_PERMITS))
 142                 readModulePermits();
 143             else if (name.equals(MODULE_CLASS))
 144                 readModuleClass();
 145             else if (name.equals(RUNTIME_VISABLE_ANNOTATION)) {
 146                 readAnnotations();
 147             } else {
 148                 in.skip(length);

switch(name) {
    case MODULE:
        readModule(); break;

    case MODULE_PROVIDES:
    ...
}

In src/share/classes/java/lang/module/ModuleSystem.java, this method body

  43     // Module names must be legal Java identifiers
  44     //
  45     public static final String checkModuleName(String nm) {
  46         if (nm == null)
  47             throw new IllegalArgumentException();
  48         int n = nm.length();
  49         if (n == 0 || !Character.isJavaIdentifierStart(nm.charAt(0)))
  50             throw new IllegalArgumentException();
  51         for (int i = 1; i < n; i++) {
  52             char c = nm.charAt(i);
  53             if (!Character.isJavaIdentifierPart(c) && (c != '.'))
  54                 throw new IllegalArgumentException(nm
  55                                                    + ": Illegal 
module-name"
  56                                                    + " character"
  57                                                    + " at index " + i);
  58         }
  59         return nm;
  60     }

could be replaced by a call to SourceVersion.isIdentifier:
http://download.java.net/jdk7/docs/api/javax/lang/model/SourceVersion.html#isIdentifier(java.lang.CharSequence)

An advantage of the isIdentifier method is that it does the right thing 
in regard to code points; see the code in
http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/71c2c23a7c35/src/share/classes/javax/lang/model/SourceVersion.java
for the codepoint-correct loop if you can't call this method.

/src/share/classes/java/lang/reflect/Module.java

Is there a reason the annotation handling code here looks different from 
the analogous code in java.lang.reflect.Constructor?

Should Module extend AccessbileObject?

src/share/classes/java/lang/module/ModuleInfoAnnotation.java

  53  * Represents an annotation in module-info.class. This class is
  54  * based on the com.sun.tools.classfile library.
  55  *
  56  * @see com.sun.tools.classfile.Annotation
 
I don't think the official javadoc of a java.lang.* class should 
reference a com.sun.* class.

As to how this class is structured, I'm not familiar with the origin of 
provenance of com.sun.tools.classfile.Annotation.  However, perhaps the 
time has come to have a unified "arms length annotation maker" to 
subsume the functionality in 
langtools/src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java 
and a similar class in javac.

src/share/classes/java/lang/module/UnsupportedElementTypeException.java

  44  */
  45 public class UnsupportedElementTypeException extends RuntimeException {
  46 
  47     private static final long serialVersionUID = 269;
  48 
  49     private transient List<String> classnames; // cannot be serialized

I assume you used javax.lang.model.type.MirroredTypeException[s] for 
inspiration here :-)  A difference is that the classname 
UnsupportedElementTypeException should be able to be serialized since it 
is just a list of strings; the MirroredTypeExceptions cannot be 
serialized because the Type objects are tied up in a lot of internal 
javac state.  (And if UnsupportedElementTypeException is made fully 
serializable, it should define a good serial form for the classname.)

As a general comment, I would encourage shell regression tests to be 
rewritten as java tests.

-Joe


From mr at sun.com  Wed Apr 28 13:51:18 2010
From: mr at sun.com (Mark Reinhold)
Date: Wed, 28 Apr 2010 13:51:18 -0700
Subject: Library delegation - should the path to parent library be the
	canonical path? 
In-Reply-To: alan.bateman@oracle.com; Mon, 19 Apr 2010 14:26:49 BST;
	<4BCC5A19.6070702@oracle.com> 
Message-ID: <20100428205118.191F2481@eggemoggin.niobe.net>

> Date: Mon, 19 Apr 2010 14:26:49 +0100
> From: alan.bateman at oracle.com

> I've been playing with the module library delegation and it looks to me that
> the path to the parent library is stored as the canonical path at the time that
> the library is created. I wonder if this will be a problem. Say in a cluster
> where the canonical path might differ depending on which node that has mounted
> the file system.

Canonical paths aren't node-dependent in NFS clusters.  Are they that way
in any other distributed filesystem?

These paths don't absolutely have to be canonical, I think, but whether
canonical, absolute, or possibly relative it will always be the case that
moving non-leaf libraries around will be problematic.

>                  Also, I assume it means that a library cannot be moved to a
> different location.

Leaf libraries can be moved trivially.  My expectation is that nearly all
non-leaf libraries will be system-defined, or at the very least always
placed in well-known locations.  So I don't expect this to be a huge
problem in practice.

>                     On that, does jmod need a "reparent" command to aid fix up
> in the event that a library is moved?

Yes, that's a good idea.

- Mark


From sean.mullan at oracle.com  Wed Apr 28 14:03:07 2010
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 28 Apr 2010 17:03:07 -0400
Subject: Minor update to signed module file format
Message-ID: <4BD8A28B.7050200@oracle.com>

I have made a very small change to the signed module file format [1]. The size 
of the signatureLength field has been changed to u4 (from u2) in order to 
accomodate signatures whose size may exceed this boundary (for example, due to 
large certificate chains, etc).

We have started the implementation and should be ready to review and putback our 
first set of changes in the next week or so. Therefore, if you are interested, 
but haven't yet reviewed the format and specification [2], please try to review 
and send your comments soon.

Thanks,
Sean

[1]: http://cr.openjdk.java.net/~mullan/jigsaw/signed-module-file-format
[2]: http://cr.openjdk.java.net/~mullan/jigsaw/signed-module-functional-spec




From mandy.chung at oracle.com  Wed Apr 28 14:08:29 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 28 Apr 2010 14:08:29 -0700
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BD8913B.3050904@Oracle.com>
References: <4BCE1DBE.6020007@oracle.com>	<4BCE4B5F.6090509@oracle.com>	<4BCE932C.9060402@oracle.com>	<4BD88392.6080903@Oracle.com>
	<4BD88AF9.2050702@oracle.com> <4BD8913B.3050904@Oracle.com>
Message-ID: <4BD8A3CD.2040304@oracle.com>

Roger Riggs wrote:
> Hi Mandy,
>
>
> Mandy Chung wrote:
>> Hi Roger,
>>
>> Thanks for the comments:
>>
>> Roger Riggs wrote:
>>> Hi,
>>>
>>> Some comments on the module APIs:
>>>
>>>    * On ModuleInfo, I would like to see an enumeration of the 
>>> Annotations;
>>>      like getAnnotations() on Module.  This will allow the caller to
>>>      iterate over
>>>      the available annotations without having to make a call to probe
>>>      for each one.
>>
>> The caller knows which annotations to look for.  You should use the 
>> isAnnotationPresent() method to check.  What's the use case to 
>> enumerate all Annotations?  What happens if a type doesn't exist?  
>> The caller will need to catch the exception if an annotation type is 
>> not found.  In that case, what would the caller do?
> The difference is in the coding style, the current API suggests/requires:
>
>        // This pattern always causes 5 calls and perhaps 5 linear 
> searches for the annotation
>     ModuleInfo m = xxx;
>
>        Annotation1 a1 = m.getAnnotation(Annotation1.class);
>     if (a1 != null) {...}
>        Annotation2 a2 = m.getAnnotation(Annotation2.class);
>     if (a1 != null) {...}
>        Annotation1 a3 = m.getAnnotation(Annotation3.class);
>     if (a1 != null) {...}
>        Annotation1 a4 = m.getAnnotation(Annotation4.class);
>     if (a1 != null) {...}
>        Annotation1 a5 = m.getAnnotation(Annotation5.class);
>     if (a1 != null) {...}
>
> vs.
>     // This pattern touches each annotation that is present only once.
>     ModuleInfo m = xxx;
>     for (Annotation a : m.getAnnotations) {
>         if (a instanceof Annotation1) {
>            Annotation1 a1 = (Annotation1)a;
>         }
>         if (a instanceof Annotation2) {
>            Annotation2 a2 = (Annotation2)a;
>         }
>         if (a instanceof Annotation3) {
>            Annotation3 a3 = (Annotation3)a;
>         }
>         if (a instanceof Annotation4) {
>            Annotation4 a4 = (Annotation4)a;
>         }
>         if (a instanceof Annotation5) {
>            Annotation5 a5 = (Annotation1)a;
>         }
>     }
>

This forces all annotations to be instantiated even if you are only 
interested in certain one.  The above loads all classes referenced by 
all annotations whereas the first example above lazily loads classes and 
creates objects.   I would assume you prefer to reference the 
annotations that you're interested in instead of all for space and time.

If one class is not found and an exception is thrown, you won't be able 
to access any of them. 

>
>
> Furthermore, if you want to write a tool the prints out the 
> annotations that are present
> it can be done conveniently.
>

I considered that.  A tool should use javax.lang.model and the 
annotation processing API to print out annotations.  There may be cases 
that you have to use ModuleInfo API rather than the tools API.  We can 
revisit this when we identify other use cases that require 
ModuleInfo.getAnnotations().   Once I push the changeset to jigsaw repo, 
this will enable you to access module-info with annotations and we can 
begin building examples and identify issues and new requirements.   How 
does that sound?
 
> Pretty much every other API that maintains a set of something provides 
> an iterator;
> ModuleInfo should too.
>

Hmm...
>>
>>>
>>>    * In the case of annotations whose values are classes (see the
>>>      getAnnotation method),
>>>      and the UnsupportedElementTypeException is thrown, under what
>>>      circumstances
>>>      will the getClassNames() method return more than one Class 
>>> name?      
>>
>> Class[]
> Ok, so it will just list the classes that are not available.

Ah.... I think you might misinterpret the spec (based on your comment 
below).  getClassNames() returns the value of the element.  For example,

@Foo(
    classes = {java.util.Map.class, java.util.Set.class}
)
------------

   Foo a = ModuleInfo.getAnnotation(Foo.class)
   try {
          a.classes()
   } catch (UnsupportedElementTypeException e) {
          System.out.println(e.getClassNames());
          // if you really want to load the Class
          Class<?> c = Class.forName(e.getClassNames().get(0));
   }

The above will print [java.util.Map, java.util.Set].  The implementation 
doesn't attempt to create the Class objects when a.classes() is called 
but instead throwing a UnsupportedElementTypeException which you can use 
the getClassNames() method to find out what classes are listed in the 
value.  You can then call Class.forName() so that you can specify which 
class loader to use.

>>
>>> A List<String> seems a bit heavyweight for this purpose.
>>
>> Why would you think it's heavyweight?  What performance concern do 
>> you have?
> Sorry, I've been working on targets where space and time always matter.
> If you don't create garbage, you don't have to clean it up.

Thanks for mentioning this.  I should have mentioned the recommendation 
in defining an annotation interface for module-info.  If an annotation 
is designed to be accessed before the module is installed, it should 
avoid defining elements of Class or Class[] type.

In that case, UnsupportedElementTypeException would not be thrown.

>>
>>>    * In the AnnotatedElement interface the TypeNotPresentException 
>>> is specified
>>>      to be thrown when the class is not accessible.  Should it be used
>>>      in ModuleInfo.getAnnotation
>>>      instead of the new UnsupportedElementTypeException?  BTW, this
>>>      name is not quite correct since
>>>      the type is just not found in the caller's type system.
>>
>> Suggestion on a better name is welcome.
> ClassNotFoundException; NoClassDefFoundException...
>
> TypeNotPresentException
>
> These are all failures because Class.forName fails because it cannot 
> find the class.
>
>>
>> As specified in the UnsupportedElementTypeException spec:
>> UnsupportedElementTypeException is thrown when an application 
>> attempts to read a |Class| object or a Class[]-valued element by 
>> invoking the relevant method on an annotation returned by the 
>> |ModuleInfo.getAnnotation(java.lang.Class| 
>> <http://cr.openjdk.java.net/%7Emchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html#getAnnotation%28java.lang.Class%29>) 
>> method.
>> The class could be found but access to elements of type Class object 
>> and Class[] is just not supported since the information necessary to 
>> locate and load a class is not available when the module is not 
>> installed. TypeNotPresentException is not appropriate for this case. 
> I understand there is no attempt to locate or define the class *in* 
> the module being inspected
> because the module is not fully defined and no classloader can be 
> created for it.
>
> But the class name(s) found in the annotations *are* being resolved using
> the caller's classloader (Class.forName() or equivalent).  If the 
> annotation class is not found
> then that is the failure that is being reported, and that is very 
> similar to ClassNotFoundException
> or TypeNotPresentException.
>

See above.
Mandy


From Roger.Riggs at oracle.com  Wed Apr 28 14:37:04 2010
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 28 Apr 2010 17:37:04 -0400
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BD8A3CD.2040304@oracle.com>
References: <4BCE1DBE.6020007@oracle.com>	<4BCE4B5F.6090509@oracle.com>	<4BCE932C.9060402@oracle.com>	<4BD88392.6080903@Oracle.com>	<4BD88AF9.2050702@oracle.com>
	<4BD8913B.3050904@Oracle.com> <4BD8A3CD.2040304@oracle.com>
Message-ID: <4BD8AA80.5040001@Oracle.com>

Hi,

Sorry this has gotten long winded...


Mandy Chung wrote:
> Roger Riggs wrote:
>> Hi Mandy,
>>
>>
>> Mandy Chung wrote:
>>> Hi Roger,
>>>
>>> Thanks for the comments:
>>>
>>> Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> Some comments on the module APIs:
>>>>
>>>>    * On ModuleInfo, I would like to see an enumeration of the 
>>>> Annotations;
>>>>      like getAnnotations() on Module.  This will allow the caller to
>>>>      iterate over
>>>>      the available annotations without having to make a call to probe
>>>>      for each one.
>>>
>>> The caller knows which annotations to look for.  You should use the 
>>> isAnnotationPresent() method to check.  What's the use case to 
>>> enumerate all Annotations?  What happens if a type doesn't exist?  
>>> The caller will need to catch the exception if an annotation type is 
>>> not found.  In that case, what would the caller do?
>> The difference is in the coding style, the current API 
>> suggests/requires:
>>
>>        // This pattern always causes 5 calls and perhaps 5 linear 
>> searches for the annotation
>>     ModuleInfo m = xxx;
>>
>>        Annotation1 a1 = m.getAnnotation(Annotation1.class);
>>     if (a1 != null) {...}
>>        Annotation2 a2 = m.getAnnotation(Annotation2.class);
>>     if (a1 != null) {...}
>>        Annotation1 a3 = m.getAnnotation(Annotation3.class);
>>     if (a1 != null) {...}
>>        Annotation1 a4 = m.getAnnotation(Annotation4.class);
>>     if (a1 != null) {...}
>>        Annotation1 a5 = m.getAnnotation(Annotation5.class);
>>     if (a1 != null) {...}
>>
>> vs.
>>     // This pattern touches each annotation that is present only once.
>>     ModuleInfo m = xxx;
>>     for (Annotation a : m.getAnnotations) {
>>         if (a instanceof Annotation1) {
>>            Annotation1 a1 = (Annotation1)a;
>>         }
>>         if (a instanceof Annotation2) {
>>            Annotation2 a2 = (Annotation2)a;
>>         }
>>         if (a instanceof Annotation3) {
>>            Annotation3 a3 = (Annotation3)a;
>>         }
>>         if (a instanceof Annotation4) {
>>            Annotation4 a4 = (Annotation4)a;
>>         }
>>         if (a instanceof Annotation5) {
>>            Annotation5 a5 = (Annotation1)a;
>>         }
>>     }
>>
>
> This forces all annotations to be instantiated even if you are only 
> interested in certain one.  The above loads all classes referenced by 
> all annotations whereas the first example above lazily loads classes 
> and creates objects.   
Providing both interfaces allows the caller to choose the access 
sequence that works best
for the caller.

> I would assume you prefer to reference the annotations that you're 
> interested in instead of all for space and time.
>
> If one class is not found and an exception is thrown, you won't be 
> able to access any of them.
This could be addressed by only returning the Accessible Annotations.
Alternatively, it could return the Annotation objects but lazily 
evaluate the bindings of the values.
Then the exception would be thrown when the Annotation value was accessed.

>>
>>
>> Furthermore, if you want to write a tool the prints out the 
>> annotations that are present
>> it can be done conveniently.
>>
>
> I considered that.  A tool should use javax.lang.model and the 
> annotation processing API to print out annotations.  There may be 
> cases that you have to use ModuleInfo API rather than the tools API.  
> We can revisit this when we identify other use cases that require 
> ModuleInfo.getAnnotations().   Once I push the changeset to jigsaw 
> repo, this will enable you to access module-info with annotations and 
> we can begin building examples and identify issues and new 
> requirements.   How does that sound?
>
>> Pretty much every other API that maintains a set of something 
>> provides an iterator;
>> ModuleInfo should too.
>>
>
> Hmm...
>>>
>>>>
>>>>    * In the case of annotations whose values are classes (see the
>>>>      getAnnotation method),
>>>>      and the UnsupportedElementTypeException is thrown, under what
>>>>      circumstances
>>>>      will the getClassNames() method return more than one Class 
>>>> name?      
>>>
>>> Class[]
>> Ok, so it will just list the classes that are not available.
>
> Ah.... I think you might misinterpret the spec (based on your comment 
> below).  getClassNames() returns the value of the element.  For example,
>
> @Foo(
>    classes = {java.util.Map.class, java.util.Set.class}
> )
> ------------
>
>   Foo a = ModuleInfo.getAnnotation(Foo.class)
>   try {
>          a.classes()
>   } catch (UnsupportedElementTypeException e) {
>          System.out.println(e.getClassNames());
>          // if you really want to load the Class
>          Class<?> c = Class.forName(e.getClassNames().get(0));
>   }
>
> The above will print [java.util.Map, java.util.Set].  The 
> implementation doesn't attempt to create the Class objects when 
> a.classes() is called but instead throwing a 
> UnsupportedElementTypeException which you can use the getClassNames() 
> method to find out what classes are listed in the value.  You can then 
> call Class.forName() so that you can specify which class loader to use.
So the API should say that it never tries to resolve values that are 
.classes (and probably enum's too)
and will always throw an exception. And it should be clear when the 
exception is thrown.

I understood that it would try to resolve the classes and only fail if 
the classes or enum's were not
available. 


Just to be clear, if there is an Annotation with multiple values then 
all of the primitive type and string
values will be accessible and the classes and enum's will not.  An the 
exception will be thrown
when the value is retrieved.  For example,

@Foo() {
     Enum Colors { RED, GREEN, BLUE};
     String first();
     int second();
     boolean third();
     Class fourth() default Object.class;
     Color fifth(); default RED;
}

And the snippet:

Foo a = ModuleInfo.getAnnotation(Foo.class)
  try {
         a.first();  // Succeeds
         a.second();  // Succeeds
         a.third();  // Succeeds
         a.fourth();  // Fails
         a.fifth();  // Would fail but doesn't get here
  } catch (UnsupportedElementTypeException e) {
         System.out.println(e.getClassNames());
         // if you really want to load the Class
         Class<?> c = Class.forName(e.getClassNames().get(0));
  }


>
>>>
>>>> A List<String> seems a bit heavyweight for this purpose.
>>>
>>> Why would you think it's heavyweight?  What performance concern do 
>>> you have?
>> Sorry, I've been working on targets where space and time always matter.
>> If you don't create garbage, you don't have to clean it up.
>
> Thanks for mentioning this.  I should have mentioned the 
> recommendation in defining an annotation interface for module-info.  
> If an annotation is designed to be accessed before the module is 
> installed, it should avoid defining elements of Class or Class[] type.
>
> In that case, UnsupportedElementTypeException would not be thrown.
>
>>>
>>>>    * In the AnnotatedElement interface the TypeNotPresentException 
>>>> is specified
>>>>      to be thrown when the class is not accessible.  Should it be used
>>>>      in ModuleInfo.getAnnotation
>>>>      instead of the new UnsupportedElementTypeException?  BTW, this
>>>>      name is not quite correct since
>>>>      the type is just not found in the caller's type system.
>>>
>>> Suggestion on a better name is welcome.
>> ClassNotFoundException; NoClassDefFoundException...
>>
>> TypeNotPresentException
>>
>> These are all failures because Class.forName fails because it cannot 
>> find the class.
>>
>>>
>>> As specified in the UnsupportedElementTypeException spec:
>>> UnsupportedElementTypeException is thrown when an application 
>>> attempts to read a |Class| object or a Class[]-valued element by 
>>> invoking the relevant method on an annotation returned by the 
>>> |ModuleInfo.getAnnotation(java.lang.Class| 
>>> <http://cr.openjdk.java.net/%7Emchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html#getAnnotation%28java.lang.Class%29>) 
>>> method.
>>> The class could be found but access to elements of type Class object 
>>> and Class[] is just not supported since the information necessary to 
>>> locate and load a class is not available when the module is not 
>>> installed. TypeNotPresentException is not appropriate for this case. 
>> I understand there is no attempt to locate or define the class *in* 
>> the module being inspected
>> because the module is not fully defined and no classloader can be 
>> created for it.
>>
>> But the class name(s) found in the annotations *are* being resolved 
>> using
>> the caller's classloader (Class.forName() or equivalent).  If the 
>> annotation class is not found
>> then that is the failure that is being reported, and that is very 
>> similar to ClassNotFoundException
>> or TypeNotPresentException.
>>
>
> See above.
> Mandy



From mandy.chung at oracle.com  Wed Apr 28 16:26:45 2010
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 28 Apr 2010 16:26:45 -0700
Subject: Please review the change to access the annotations from
	module-info
In-Reply-To: <4BD89B34.1070708@oracle.com>
References: <4BD7D385.4030602@oracle.com> <4BD89B34.1070708@oracle.com>
Message-ID: <4BD8C435.1060505@oracle.com>

Joe,

Thanks for the review.

Joe Darcy wrote:
> Hello.
>
> Some comments from a first pass over the code:
>
> In ModuleInfo.java, I recommend adding an "@see 
> java.lang.reflect.AnnotatedElement#isAnnotationPresent" to the 
> isAnnotationPresent method.
>

Added.

> In ModuleInfoReader.java, if you want to start using some new language 
> features, the following line is an ideal candidate for the diamond 
> operator:
>

Thanks for the new language features.  Will switch to use that.

> 70     private Map<String, ModuleInfoAnnotation> annotationTypes = new 
> LinkedHashMap<String, ModuleInfoAnnotation>();
>
> With diamond
>
> 70     private Map<String, ModuleInfoAnnotation> annotationTypes = new 
> LinkedHashMap<>();
>
> Later in that file, this looks like a candidate for strings in switch:
>
> 135             if (name.equals(MODULE))
> 136                 readModule();
> 137             else if (name.equals(MODULE_PROVIDES))
> 138                 readModuleProvides();
> 139             else if (name.equals(MODULE_REQUIRES))
> 140                 readModuleRequires();
> 141             else if (name.equals(MODULE_PERMITS))
> 142                 readModulePermits();
> 143             else if (name.equals(MODULE_CLASS))
> 144                 readModuleClass();
> 145             else if (name.equals(RUNTIME_VISABLE_ANNOTATION)) {
> 146                 readAnnotations();
> 147             } else {
> 148                 in.skip(length);
>
> switch(name) {
>    case MODULE:
>        readModule(); break;
>
>    case MODULE_PROVIDES:
>    ...
> }
>
> In src/share/classes/java/lang/module/ModuleSystem.java, this method body
>
>  43     // Module names must be legal Java identifiers
>  44     //
>  45     public static final String checkModuleName(String nm) {
>  46         if (nm == null)
>  47             throw new IllegalArgumentException();
>  48         int n = nm.length();
>  49         if (n == 0 || !Character.isJavaIdentifierStart(nm.charAt(0)))
>  50             throw new IllegalArgumentException();
>  51         for (int i = 1; i < n; i++) {
>  52             char c = nm.charAt(i);
>  53             if (!Character.isJavaIdentifierPart(c) && (c != '.'))
>  54                 throw new IllegalArgumentException(nm
>  55                                                    + ": Illegal 
> module-name"
>  56                                                    + " character"
>  57                                                    + " at index " 
> + i);
>  58         }
>  59         return nm;
>  60     }
>
> could be replaced by a call to SourceVersion.isIdentifier:
> http://download.java.net/jdk7/docs/api/javax/lang/model/SourceVersion.html#isIdentifier(java.lang.CharSequence) 
>
>
> An advantage of the isIdentifier method is that it does the right 
> thing in regard to code points; see the code in
> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/71c2c23a7c35/src/share/classes/javax/lang/model/SourceVersion.java 
>
> for the codepoint-correct loop if you can't call this method.
>
Thanks for the pointer.   I'll replace it with the codepoint correct 
loop.  javax.lang.model is not in the boot module and so we can't call it.

> /src/share/classes/java/lang/reflect/Module.java
>
> Is there a reason the annotation handling code here looks different 
> from the analogous code in java.lang.reflect.Constructor?
>

module-info.class is not loaded as a Class.  Instead, it's parsed by 
ModuleInfoReader.  So we can't use AnnotationParser.parseAnnotations 
unless we create a ClassLoader to load module-info.class into the VM.

> Should Module extend AccessbileObject?
>

Good question.  I don't think so.  Alex and Mark, what do you think?

> src/share/classes/java/lang/module/ModuleInfoAnnotation.java
>
>  53  * Represents an annotation in module-info.class. This class is
>  54  * based on the com.sun.tools.classfile library.
>  55  *
>  56  * @see com.sun.tools.classfile.Annotation
>
> I don't think the official javadoc of a java.lang.* class should 
> reference a com.sun.* class.

I can take that out.  The ModuleInfoAnnotation is a package-private 
class and so I would think it's okay.
>
> As to how this class is structured, I'm not familiar with the origin 
> of provenance of com.sun.tools.classfile.Annotation.  However, perhaps 
> the time has come to have a unified "arms length annotation maker" to 
> subsume the functionality in 
> langtools/src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java 
> and a similar class in javac.
>
> src/share/classes/java/lang/module/UnsupportedElementTypeException.java
>
>  44  */
>  45 public class UnsupportedElementTypeException extends 
> RuntimeException {
>  46  47     private static final long serialVersionUID = 269;
>  48  49     private transient List<String> classnames; // cannot be 
> serialized
>
> I assume you used javax.lang.model.type.MirroredTypeException[s] for 
> inspiration here :-)  

I copied from MirroredTypeExceptions but forget to clean it up :)
> A difference is that the classname UnsupportedElementTypeException 
> should be able to be serialized since it is just a list of strings; 
> the MirroredTypeExceptions cannot be serialized because the Type 
> objects are tied up in a lot of internal javac state.  (And if 
> UnsupportedElementTypeException is made fully serializable, it should 
> define a good serial form for the classname.)
>
Will clean that up.

> As a general comment, I would encourage shell regression tests to be 
> rewritten as java tests.
>

It was good to know that langtools shell regression tests were converted 
to java tests.  I will do that some time.

Mandy


From Dalibor.Topic at Sun.COM  Thu Apr 29 05:49:17 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 29 Apr 2010 14:49:17 +0200
Subject: [for review] 6948144: jpkg throws NPE if resource directory does not
	exist
Message-ID: <4BD9804D.9060807@sun.com>

Hi Alan,

thanks for reporting a NPE with
$ jpkg -m existing-dir -r non-existing-dir jmod some-mod

the fix is easy - test whether the resource path exists before passing
it on to module file writer ;) The webrev is at
http://cr.openjdk.java.net/~robilad/6948144/webrev.00/

Once this one is in, I'll commit similar tests for the remaining parameters.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic 			Tel: (+49 40) 23 646 738
Java F/OSS Ambassador 		AIM: robiladonaim
Sun Microsystems GmbH 		Mobile: (+49 177) 2664 192
Nagelsweg 55 			http://openjdk.java.net
D-20097 Hamburg 		mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: J?rgen Kunz


From Alan.Bateman at oracle.com  Thu Apr 29 07:02:59 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Apr 2010 15:02:59 +0100
Subject: [for review] 6948144: jpkg throws NPE if resource directory does
	not exist
In-Reply-To: <4BD9804D.9060807@sun.com>
References: <4BD9804D.9060807@sun.com>
Message-ID: <4BD99193.6060603@oracle.com>

Dalibor Topic wrote:
> Hi Alan,
>
> thanks for reporting a NPE with
> $ jpkg -m existing-dir -r non-existing-dir jmod some-mod
>
> the fix is easy - test whether the resource path exists before passing
> it on to module file writer ;) The webrev is at
> http://cr.openjdk.java.net/~robilad/6948144/webrev.00/
>
> Once this one is in, I'll commit similar tests for the remaining parameters.
>
> cheers,
> dalibor topic
>   
The fix looks OK to me. I'm not sure about the name of the test though 
as it doesn't seem to be consistent with the other tests. In time it can 
be useful to expand existing tests with additional tests.

-Alan.


From Dalibor.Topic at Sun.COM  Thu Apr 29 07:54:52 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 29 Apr 2010 16:54:52 +0200
Subject: [for review] 6948144: jpkg throws NPE if resource directory does
	not exist
In-Reply-To: <4BD99193.6060603@oracle.com>
References: <4BD9804D.9060807@sun.com> <4BD99193.6060603@oracle.com>
Message-ID: <4BD99DBC.1030502@sun.com>

Alan Bateman wrote:
> Dalibor Topic wrote:
>> Hi Alan,
>>
>> thanks for reporting a NPE with
>> $ jpkg -m existing-dir -r non-existing-dir jmod some-mod
>>
>> the fix is easy - test whether the resource path exists before passing
>> it on to module file writer ;) The webrev is at
>> http://cr.openjdk.java.net/~robilad/6948144/webrev.00/
>>
>> Once this one is in, I'll commit similar tests for the remaining
>> parameters.
>>
>> cheers,
>> dalibor topic
>>   
> The fix looks OK to me. I'm not sure about the name of the test though
> as it doesn't seem to be consistent with the other tests. In time it can
> be useful to expand existing tests with additional tests.

How about calling is JpkgTestInputParameters? Then expanding the
test to cover more of the cases will feel rather natural.

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: J?rgen Kunz




From akhil.arora at oracle.com  Thu Apr 29 08:54:41 2010
From: akhil.arora at oracle.com (Akhil Arora)
Date: Thu, 29 Apr 2010 08:54:41 -0700
Subject: make jpkg resource path absolute
Message-ID: <724C5461-563C-4B52-89B1-D5ABEE76E549@oracle.com>

I had a question about jpkg's -r option - it seems like the value of - 
r is relative to the current directory. This forces a build tool to cd  
to a certain directory before invoking jpkg, which is not good because  
the script has to remember to  cd back after. Would it be possible to  
make the value of -r an absolute path? Thanks


From Alan.Bateman at oracle.com  Thu Apr 29 13:34:21 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Apr 2010 21:34:21 +0100
Subject: 6946751
Message-ID: <4BD9ED4D.1020206@oracle.com>

Mark - I need to fix 6946751 as it currently prevents anyone from using 
jmod to install jmod packages that don't contain any class files (except 
for the module-info class of course). The issue seems to be the indexing 
that it done when installing. It looks like this can be easily fixed in 
SimpleLibrary.reIndex(ModuleId) so that it skips walking the classes 
when it doesn't exist. Is there anything else that I need to know to fix 
this?

Thanks,
Alan.



From Alan.Bateman at oracle.com  Thu Apr 29 14:04:08 2010
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Apr 2010 22:04:08 +0100
Subject: [for review] 6948144: jpkg throws NPE if resource directory does
	not exist
In-Reply-To: <4BD99DBC.1030502@sun.com>
References: <4BD9804D.9060807@sun.com> <4BD99193.6060603@oracle.com>
	<4BD99DBC.1030502@sun.com>
Message-ID: <4BD9F448.9010701@oracle.com>

Dalibor Topic wrote:
> :
> How about calling is JpkgTestInputParameters? Then expanding the
> test to cover more of the cases will feel rather natural.
>   
JpkgArgsTest could work but I don't have a strong preference. Thanks for 
fixing this one (it was actually Akhil that asked me about it, which is 
why I created the bug).

-Alan.


From mandy.chung at oracle.com  Thu Apr 29 14:10:35 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 29 Apr 2010 21:10:35 +0000
Subject: hg: jigsaw/jigsaw/jdk: 2 new changesets
Message-ID: <20100429211119.563574436B@hg.openjdk.java.net>

Changeset: 60aa4a4ff8da
Author:    mchung
Date:      2010-04-29 14:08 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/60aa4a4ff8da

Add API to access annotations in ModuleInfo
Reviewed-by: darcy

! make/java/java/FILES_java.gmk
! src/share/classes/java/lang/module/ModuleClassLoader.java
! src/share/classes/java/lang/module/ModuleInfo.java
+ src/share/classes/java/lang/module/ModuleInfoAnnotation.java
! src/share/classes/java/lang/module/ModuleInfoReader.java
! src/share/classes/java/lang/module/ModuleSystem.java
+ src/share/classes/java/lang/module/UnsupportedElementTypeException.java
! src/share/classes/java/lang/reflect/Module.java
! src/share/classes/java/lang/reflect/ReflectAccess.java
+ src/share/classes/sun/misc/JavaLangModuleAccess.java
! src/share/classes/sun/misc/SharedSecrets.java
! src/share/classes/sun/reflect/LangReflectAccess.java
! src/share/classes/sun/reflect/ReflectionFactory.java
! src/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java
+ test/java/lang/module/ModuleAnnotationTest.java
+ test/java/lang/module/module-info-annotation.sh
+ test/java/lang/reflect/Module/ModuleAnnotationTest.java
+ test/java/lang/reflect/Module/module-annotation.sh
! test/org/openjdk/jigsaw/ModuleInfoBuilder.java

Changeset: df5412c42a80
Author:    mchung
Date:      2010-04-29 14:10 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/df5412c42a80

Merge




From mark.reinhold at oracle.com  Thu Apr 29 14:48:58 2010
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 29 Apr 2010 14:48:58 -0700
Subject: 6946751 
In-Reply-To: alan.bateman@oracle.com; Thu, 29 Apr 2010 21:34:21 BST;
	<4BD9ED4D.1020206@oracle.com> 
Message-ID: <20100429214858.36E1B2AE@eggemoggin.niobe.net>

> Date: Thu, 29 Apr 2010 21:34:21 +0100
> From: alan.bateman at oracle.com

> Mark - I need to fix 6946751 as it currently prevents anyone from using jmod to
> install jmod packages that don't contain any class files (except for the
> module-info class of course). The issue seems to be the indexing that it done
> when installing. It looks like this can be easily fixed in
> SimpleLibrary.reIndex(ModuleId) so that it skips walking the classes when it
> doesn't exist. Is there anything else that I need to know to fix this?

No -- that should do the trick.

- Mark


From mandy.chung at oracle.com  Thu Apr 29 15:16:34 2010
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 29 Apr 2010 22:16:34 +0000
Subject: hg: jigsaw/jigsaw/jdk: Normalizing the jigsaw source and tests
Message-ID: <20100429221647.CC6244437C@hg.openjdk.java.net>

Changeset: 9fffacdf4115
Author:    mchung
Date:      2010-04-29 15:16 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/9fffacdf4115

Normalizing the jigsaw source and tests

! src/share/classes/java/lang/module/ModuleInfo.java
! src/share/classes/java/lang/module/ModuleInfoAnnotation.java
! src/share/classes/java/lang/module/ModuleInfoReader.java
! src/share/classes/java/lang/module/ModuleSystem.java
! src/share/classes/java/lang/module/UnsupportedElementTypeException.java
! src/share/classes/java/lang/reflect/Module.java
! src/share/classes/org/openjdk/internal/joptsimple/internal/Strings.java
! src/share/classes/org/openjdk/jigsaw/Configurator.java
! src/share/classes/org/openjdk/jigsaw/Files.java
! src/share/classes/org/openjdk/jigsaw/Library.java
! src/share/classes/org/openjdk/jigsaw/Linker.java
! src/share/classes/org/openjdk/jigsaw/Loader.java
! src/share/classes/org/openjdk/jigsaw/ModuleFileFormat.java
! src/share/classes/org/openjdk/jigsaw/PathContext.java
! src/share/classes/org/openjdk/jigsaw/PublishedRepository.java
! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java
! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java
! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
! test/java/lang/module/ModuleAnnotationTest.java
! test/java/lang/module/_ModuleId.java
! test/java/lang/module/_ModuleInfoReader.java
! test/java/lang/reflect/Module/ModuleAnnotationTest.java
! test/org/openjdk/jigsaw/ConfigurationBuilder.java
! test/org/openjdk/jigsaw/ContextBuilder.java
! test/org/openjdk/jigsaw/MockLibrary.java
! test/org/openjdk/jigsaw/ModuleInfoBuilder.java
! test/org/openjdk/jigsaw/TrivialWebServer.java
! test/org/openjdk/jigsaw/_Configurator.java
! test/org/openjdk/jigsaw/_JigsawVersion.java
! test/org/openjdk/jigsaw/_JigsawVersionQuery.java
! test/org/openjdk/jigsaw/_Library.java
! test/org/openjdk/jigsaw/_PublishedRepository.java
! test/org/openjdk/jigsaw/_RemoteRepository.java
! test/org/openjdk/jigsaw/_RemoteRepositoryList.java
! test/org/openjdk/jigsaw/_RepositoryCatalog.java
! test/org/openjdk/jigsaw/cli/ModuleFormatHeaderHashTest.java
! test/org/openjdk/jigsaw/cli/ModuleFormatTest01.java
! test/org/openjdk/jigsaw/cli/ModuleFormatTestLeftOverBytes.java



From jonathan.gibbons at sun.com  Thu Apr 29 16:09:38 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 29 Apr 2010 23:09:38 +0000
Subject: hg: jigsaw/jigsaw/jdk: Fix incompatible use of diamond operator
Message-ID: <20100429230950.942C844388@hg.openjdk.java.net>

Changeset: 27ed1ea841de
Author:    jjg
Date:      2010-04-29 16:08 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/27ed1ea841de

Fix incompatible use of diamond operator

! src/share/classes/org/openjdk/jigsaw/Linker.java



From jonathan.gibbons at sun.com  Thu Apr 29 16:11:23 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 29 Apr 2010 23:11:23 +0000
Subject: hg: jigsaw/jigsaw/langtools: 13 new changesets
Message-ID: <20100429231147.2985F44389@hg.openjdk.java.net>

Changeset: 96072ad00783
Author:    jjg
Date:      2010-04-09 15:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/96072ad00783

6942649: add hidden option to identify location and version of javac classes
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/Main.java
+ test/tools/javac/T6942649.java

Changeset: 396b117c1743
Author:    mcimadamore
Date:      2010-04-14 12:23 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/396b117c1743

6939618: Revert 'simple' diamond implementation
Summary: backout changeset for 6840638
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
- test/tools/javac/generics/diamond/neg/Neg01.java
- test/tools/javac/generics/diamond/neg/Neg01.out
- test/tools/javac/generics/diamond/neg/Neg02.java
- test/tools/javac/generics/diamond/neg/Neg02.out
- test/tools/javac/generics/diamond/neg/Neg03.java
- test/tools/javac/generics/diamond/neg/Neg03.out
- test/tools/javac/generics/diamond/neg/Neg04.java
- test/tools/javac/generics/diamond/neg/Neg04.out
- test/tools/javac/generics/diamond/neg/Neg05.java
- test/tools/javac/generics/diamond/neg/Neg05.out
- test/tools/javac/generics/diamond/pos/Pos01.java
- test/tools/javac/generics/diamond/pos/Pos02.java
- test/tools/javac/generics/diamond/pos/Pos03.java
- test/tools/javac/generics/diamond/pos/Pos04.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java

Changeset: 9d9d08922405
Author:    mcimadamore
Date:      2010-04-14 12:31 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9d9d08922405

6939620: Switch to 'complex' diamond inference scheme
Summary: Implement new inference scheme for diamond operator that takes into account type of actual arguments supplied to constructor
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! test/tools/javac/6840059/T6840059.out
+ test/tools/javac/generics/diamond/neg/Neg01.java
+ test/tools/javac/generics/diamond/neg/Neg01.out
+ test/tools/javac/generics/diamond/neg/Neg02.java
+ test/tools/javac/generics/diamond/neg/Neg02.out
+ test/tools/javac/generics/diamond/neg/Neg03.java
+ test/tools/javac/generics/diamond/neg/Neg03.out
+ test/tools/javac/generics/diamond/neg/Neg04.java
+ test/tools/javac/generics/diamond/neg/Neg04.out
+ test/tools/javac/generics/diamond/neg/Neg05.java
+ test/tools/javac/generics/diamond/neg/Neg05.out
+ test/tools/javac/generics/diamond/neg/Neg06.java
+ test/tools/javac/generics/diamond/neg/Neg06.out
+ test/tools/javac/generics/diamond/neg/Neg07.java
+ test/tools/javac/generics/diamond/neg/Neg07.out
+ test/tools/javac/generics/diamond/neg/Neg08.java
+ test/tools/javac/generics/diamond/neg/Neg08.out
+ test/tools/javac/generics/diamond/neg/Neg09.java
+ test/tools/javac/generics/diamond/neg/Neg09.out
+ test/tools/javac/generics/diamond/neg/Neg10.java
+ test/tools/javac/generics/diamond/neg/Neg10.out
+ test/tools/javac/generics/diamond/neg/Neg11.java
+ test/tools/javac/generics/diamond/neg/Neg11.out
+ test/tools/javac/generics/diamond/pos/Pos01.java
+ test/tools/javac/generics/diamond/pos/Pos02.java
+ test/tools/javac/generics/diamond/pos/Pos03.java
+ test/tools/javac/generics/diamond/pos/Pos04.java
+ test/tools/javac/generics/diamond/pos/Pos05.java

Changeset: 409db93d19c0
Author:    mikejwre
Date:      2010-03-18 13:53 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/409db93d19c0

Added tag jdk7-b86 for changeset ef07347428f2

! .hgtags

Changeset: f9b5d4867a26
Author:    mikejwre
Date:      2010-03-25 15:05 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f9b5d4867a26

Added tag jdk7-b87 for changeset 409db93d19c0

! .hgtags

Changeset: 737185f3300f
Author:    mikejwre
Date:      2010-04-08 17:03 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/737185f3300f

Added tag jdk7-b88 for changeset f9b5d4867a26

! .hgtags

Changeset: ad1bf317cc57
Author:    lana
Date:      2010-04-08 15:35 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ad1bf317cc57

Merge

- test/tools/javap/T6305779.java

Changeset: 6cea9a143208
Author:    lana
Date:      2010-04-13 16:42 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6cea9a143208

Merge

- test/tools/javap/T6305779.java

Changeset: 71c2c23a7c35
Author:    mikejwre
Date:      2010-04-15 13:55 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/71c2c23a7c35

Added tag jdk7-b89 for changeset 6cea9a143208

! .hgtags

Changeset: 37fa8cd046ab
Author:    lana
Date:      2010-04-17 08:12 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/37fa8cd046ab

Merge


Changeset: 04cf82179fa7
Author:    mcimadamore
Date:      2010-04-21 12:24 +0100
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/04cf82179fa7

6730476: invalid "unchecked generic array" warning
Summary: Reifiable-ness of varargs element type should be checked after JLS3 15.12.2.8
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/varargs/6730476/T6730476a.java
+ test/tools/javac/varargs/6730476/T6730476b.java

Changeset: 32675c68a3ca
Author:    jjg
Date:      2010-04-29 14:25 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/32675c68a3ca

6948251: need to quote args in langtools launcher script
Reviewed-by: darcy

! src/share/bin/launcher.sh-template

Changeset: 1d3e1ab9bfcc
Author:    jjg
Date:      2010-04-29 14:36 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1d3e1ab9bfcc

Merge

! .hgtags
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! test/tools/javac/generics/diamond/neg/Neg01.java
! test/tools/javac/generics/diamond/neg/Neg01.out
! test/tools/javac/generics/diamond/neg/Neg02.java
! test/tools/javac/generics/diamond/neg/Neg02.out
! test/tools/javac/generics/diamond/neg/Neg03.java
! test/tools/javac/generics/diamond/neg/Neg03.out
! test/tools/javac/generics/diamond/neg/Neg04.java
! test/tools/javac/generics/diamond/neg/Neg04.out
! test/tools/javac/generics/diamond/neg/Neg05.java
! test/tools/javac/generics/diamond/neg/Neg05.out
! test/tools/javac/generics/diamond/pos/Pos01.java
! test/tools/javac/generics/diamond/pos/Pos02.java
! test/tools/javac/generics/diamond/pos/Pos03.java
! test/tools/javac/generics/diamond/pos/Pos04.java



From jonathan.gibbons at oracle.com  Wed Apr 28 12:32:41 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Apr 2010 12:32:41 -0700
Subject: ModuleInfo extends AnnotatedElement
In-Reply-To: <4BD88AF9.2050702@oracle.com>
References: <4BCE1DBE.6020007@oracle.com> <4BCE4B5F.6090509@oracle.com>
	<4BCE932C.9060402@oracle.com> <4BD88392.6080903@Oracle.com>
	<4BD88AF9.2050702@oracle.com>
Message-ID: <4BD88D59.4010806@oracle.com>

Roger,

One more answer ...

Mandy Chung wrote:
> Hi Roger,
>
> Thanks for the comments:
>
> Roger Riggs wrote:
>> Hi,
>>
>> Some comments on the module APIs:
>>
>>    * On ModuleInfo, I would like to see an enumeration of the 
>> Annotations;
>>      like getAnnotations() on Module.  This will allow the caller to
>>      iterate over
>>      the available annotations without having to make a call to probe
>>      for each one.
>
> The caller knows which annotations to look for.  You should use the 
> isAnnotationPresent() method to check.  What's the use case to 
> enumerate all Annotations?  What happens if a type doesn't exist?  The 
> caller will need to catch the exception if an annotation type is not 
> found.  In that case, what would the caller do?
>
>>    * Style: Should there be more symmetry between Module and ModuleInfo
>>      APIs?
>>      ModuleInfo returns Set<x>, while Module returns Annotation[] 
>> arrays.
>>      Use of arrays generally requires that they be copied; creating
>>      garbage.
>
> Joe can help explain the reason why AnnotatedElement.getAnnotations() 
> returns Annotation[].
>
>>    * In the ModuleInfo.permits() method it returns a Set<String>;
>>      in contrast the provides() method returns a Set<ModuleId>.      
>> Is there a reason that String is used instead of a ModuleId?

permits take a module name with no version info. Therefore a String is 
the obvious representation.



>>    * Are the sets returned from permits(), requires(), provides()
>>      modifiable by
>>      the caller?  
> unmodifiable.  Will make it clear in the spec.
>> It would be good to be clear about whether they are
>>      copies
>>      of the internal structures or are read-only to prevent corruption.
>>      Read-only would
>>      be better and create less garbage.
>>    * In the case of annotations whose values are classes (see the
>>      getAnnotation method),
>>      and the UnsupportedElementTypeException is thrown, under what
>>      circumstances
>>      will the getClassNames() method return more than one Class name? 
>>      
>
> Class[]
>
>> A List<String> seems a bit heavyweight for this purpose.
>
> Why would you think it's heavyweight?  What performance concern do you 
> have?
>
>>    * In the AnnotatedElement interface the TypeNotPresentException is
>>      specified
>>      to be thrown when the class is not accessible.  Should it be used
>>      in ModuleInfo.getAnnotation
>>      instead of the new UnsupportedElementTypeException?  BTW, this
>>      name is not quite correct since
>>      the type is just not found in the caller's type system.
>
> Suggestion on a better name is welcome.
>
> As specified in the UnsupportedElementTypeException spec:
> UnsupportedElementTypeException is thrown when an application attempts 
> to read a |Class| object or a Class[]-valued element by invoking the 
> relevant method on an annotation returned by the 
> |ModuleInfo.getAnnotation(java.lang.Class| 
> <http://cr.openjdk.java.net/%7Emchung/jigsaw/annotations/api/java/lang/module/ModuleInfo.html#getAnnotation%28java.lang.Class%29>) 
> method.
> The class could be found but access to elements of type Class object 
> and Class[] is just not supported since the information necessary to 
> locate and load a class is not available when the module is not 
> installed. TypeNotPresentException is not appropriate for this case. 
> Thanks
> Mandy



From jonathan.gibbons at oracle.com  Wed Apr 28 14:22:44 2010
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Apr 2010 14:22:44 -0700
Subject: Library delegation - should the path to parent library be the
	canonical path?
In-Reply-To: <20100428205118.191F2481@eggemoggin.niobe.net>
References: <20100428205118.191F2481@eggemoggin.niobe.net>
Message-ID: <4BD8A724.3050202@oracle.com>

Mark Reinhold wrote:
>> Date: Mon, 19 Apr 2010 14:26:49 +0100
>> From: alan.bateman at oracle.com
>>     
>
>   
>> I've been playing with the module library delegation and it looks to me that
>> the path to the parent library is stored as the canonical path at the time that
>> the library is created. I wonder if this will be a problem. Say in a cluster
>> where the canonical path might differ depending on which node that has mounted
>> the file system.
>>     
>
> Canonical paths aren't node-dependent in NFS clusters.  Are they that way
> in any other distributed filesystem?
>
> These paths don't absolutely have to be canonical, I think, but whether
> canonical, absolute, or possibly relative it will always be the case that
> moving non-leaf libraries around will be problematic.
>
>   
>>                  Also, I assume it means that a library cannot be moved to a
>> different location.
>>     
>
> Leaf libraries can be moved trivially.  My expectation is that nearly all
> non-leaf libraries will be system-defined, or at the very least always
> placed in well-known locations.  So I don't expect this to be a huge
> problem in practice.
>   

I think it will be very common for developers to have transient 
libraries.  I agree that moving them will not be a problem, but at least 
as a developer I think that such transient libraries will be if anything 
more common than system libraries.


>   
>>                     On that, does jmod need a "reparent" command to aid fix up
>> in the event that a library is moved?
>>     
>
> Yes, that's a good idea.
>
> - Mark
>   



From Dalibor.Topic at Sun.COM  Fri Apr 30 02:08:52 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 30 Apr 2010 11:08:52 +0200
Subject: make jpkg resource path absolute
In-Reply-To: <724C5461-563C-4B52-89B1-D5ABEE76E549@oracle.com>
References: <724C5461-563C-4B52-89B1-D5ABEE76E549@oracle.com>
Message-ID: <4BDA9E24.8090806@sun.com>

Akhil Arora wrote:
> I had a question about jpkg's -r option - it seems like the value of -r
> is relative to the current directory. This forces a build tool to cd to
> a certain directory before invoking jpkg, which is not good because the
> script has to remember to  cd back after. Would it be possible to make
> the value of -r an absolute path? Thanks

I think so. I'll hack on a patch for that later today.

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: J?rgen Kunz




From jonathan.gibbons at sun.com  Fri Apr 30 08:39:52 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 30 Apr 2010 15:39:52 +0000
Subject: hg: jigsaw/jigsaw/jdk: build apt in legacy mode
Message-ID: <20100430154005.CBBDA4450D@hg.openjdk.java.net>

Changeset: 335c06fc02bf
Author:    jjg
Date:      2010-04-30 08:39 -0700
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/335c06fc02bf

build apt in legacy mode

! make/launchers/Makefile



From dalibor.topic at sun.com  Fri Apr 30 12:44:03 2010
From: dalibor.topic at sun.com (dalibor.topic at sun.com)
Date: Fri, 30 Apr 2010 19:44:03 +0000
Subject: hg: jigsaw/jigsaw/jdk: 6948144: jpkg throws NPE if resource directory
	does not exist
Message-ID: <20100430194416.6206944560@hg.openjdk.java.net>

Changeset: 0c4117c37a35
Author:    robilad
Date:      2010-04-30 21:40 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0c4117c37a35

6948144: jpkg throws NPE if resource directory does not exist
Summary: Check if a resource dir exists before using it
Reviewed-by: alanb

! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
+ test/org/openjdk/jigsaw/cli/JpkgArgsTest.java



From akhil.arora at oracle.com  Fri Apr 30 13:07:01 2010
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 30 Apr 2010 13:07:01 -0700
Subject: hg: jigsaw/jigsaw/jdk: 6948144: jpkg throws NPE if resource
	directory does not exist
In-Reply-To: <20100430194416.6206944560@hg.openjdk.java.net>
References: <20100430194416.6206944560@hg.openjdk.java.net>
Message-ID: <4BDB3865.3020106@oracle.com>

I noticed today that a similar exception is generated if a dir specified 
as the value of the -natlib arg does not exist.

On 04/30/2010 12:44 PM, dalibor.topic at sun.com wrote:
> Changeset: 0c4117c37a35
> Author:    robilad
> Date:      2010-04-30 21:40 +0200
> URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0c4117c37a35
> 
> 6948144: jpkg throws NPE if resource directory does not exist
> Summary: Check if a resource dir exists before using it
> Reviewed-by: alanb
> 
> ! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
> + test/org/openjdk/jigsaw/cli/JpkgArgsTest.java
> 



From Dalibor.Topic at Sun.COM  Fri Apr 30 13:10:51 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 30 Apr 2010 22:10:51 +0200
Subject: hg: jigsaw/jigsaw/jdk: 6948144: jpkg throws NPE if resource
	directory does not exist
In-Reply-To: <4BDB3865.3020106@oracle.com>
References: <20100430194416.6206944560@hg.openjdk.java.net>
	<4BDB3865.3020106@oracle.com>
Message-ID: <4BDB394B.7050809@sun.com>

Akhil Arora wrote:
> I noticed today that a similar exception is generated if a dir specified 
> as the value of the -natlib arg does not exist.
> 

Yeah, I'm adding tests for the other jpkg arguments and fixes atm.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: J?rgen Kunz




From Dalibor.Topic at Sun.COM  Fri Apr 30 13:16:44 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 30 Apr 2010 22:16:44 +0200
Subject: hg: jigsaw/jigsaw/jdk: 6948144: jpkg throws NPE if resource
	directory does not exist
In-Reply-To: <4BDB394B.7050809@sun.com>
References: <20100430194416.6206944560@hg.openjdk.java.net>
	<4BDB3865.3020106@oracle.com> <4BDB394B.7050809@sun.com>
Message-ID: <4BDB3AAC.9040201@sun.com>

Dalibor Topic wrote:
> Akhil Arora wrote:
>> I noticed today that a similar exception is generated if a dir 
>> specified as the value of the -natlib arg does not exist.
>>
> 
> Yeah, I'm adding tests for the other jpkg arguments and fixes atm.

Oh and thanks! Keep the bug reports flowing!

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: J?rgen Kunz




From mr at sun.com  Fri Apr 30 13:25:17 2010
From: mr at sun.com (Mark Reinhold)
Date: Fri, 30 Apr 2010 13:25:17 -0700
Subject: make jpkg resource path absolute 
In-Reply-To: akhil.arora@oracle.com; Thu, 29 Apr 2010 08:54:41 PDT;
	<724C5461-563C-4B52-89B1-D5ABEE76E549@oracle.com> 
Message-ID: <20100430202517.533E33AD@eggemoggin.niobe.net>

> Date: Thu, 29 Apr 2010 08:54:41 -0700
> From: akhil.arora at oracle.com

> I had a question about jpkg's -r option - it seems like the value of -
> r is relative to the current directory. This forces a build tool to cd to a
> certain directory before invoking jpkg, which is not good because  the script
> has to remember to  cd back after. Would it be possible to  make the value of
> -r an absolute path? Thanks

Not sure what you mean here.  The argument to -r should be interpreted
relative to the current directory if the argument is relative.

Are you saying that if you pass an absolute path to -r then it's not
interpreted as absolute?  That would be a bug.

- Mark


From akhil.arora at oracle.com  Fri Apr 30 13:27:04 2010
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 30 Apr 2010 13:27:04 -0700
Subject: make jpkg resource path absolute
In-Reply-To: <20100430202517.533E33AD@eggemoggin.niobe.net>
References: <20100430202517.533E33AD@eggemoggin.niobe.net>
Message-ID: <4BDB3D18.9000709@oracle.com>

On 04/30/2010 01:25 PM, Mark Reinhold wrote:
>> Date: Thu, 29 Apr 2010 08:54:41 -0700
>> From: akhil.arora at oracle.com
> 
>> I had a question about jpkg's -r option - it seems like the value of -
>> r is relative to the current directory. This forces a build tool to cd to a
>> certain directory before invoking jpkg, which is not good because  the script
>> has to remember to  cd back after. Would it be possible to  make the value of
>> -r an absolute path? Thanks
> 
> Not sure what you mean here.  The argument to -r should be interpreted
> relative to the current directory if the argument is relative.
> 
> Are you saying that if you pass an absolute path to -r then it's not
> interpreted as absolute?  That would be a bug.

An absolute path passed to -r is not accepted at all - jpkg insists on 
being given a relative path for -r.


From dalibor.topic at sun.com  Fri Apr 30 13:32:06 2010
From: dalibor.topic at sun.com (dalibor.topic at sun.com)
Date: Fri, 30 Apr 2010 20:32:06 +0000
Subject: hg: jigsaw/jigsaw/jdk: Check if natlib directory exists before use
Message-ID: <20100430203219.544F94457E@hg.openjdk.java.net>

Changeset: ae57e9461b54
Author:    robilad
Date:      2010-04-30 22:31 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/ae57e9461b54

Check if natlib directory exists before use

! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
! test/org/openjdk/jigsaw/cli/JpkgArgsTest.java



From mr at sun.com  Fri Apr 30 13:33:00 2010
From: mr at sun.com (Mark Reinhold)
Date: Fri, 30 Apr 2010 13:33:00 -0700
Subject: make jpkg resource path absolute 
In-Reply-To: akhil.arora@oracle.com; Fri, 30 Apr 2010 13:27:04 PDT;
	<4BDB3D18.9000709@oracle.com> 
Message-ID: <20100430203300.20B1A3AD@eggemoggin.niobe.net>

> Date: Fri, 30 Apr 2010 13:27:04 -0700
> From: akhil.arora at oracle.com

> On 04/30/2010 01:25 PM, Mark Reinhold wrote:
>> Are you saying that if you pass an absolute path to -r then it's not
>> interpreted as absolute?  That would be a bug.
> 
> An absolute path passed to -r is not accepted at all - jpkg insists on being
> given a relative path for -r.

Yow, that's even worse!  Definitely a bug.

- Mark


From dalibor.topic at sun.com  Fri Apr 30 14:03:25 2010
From: dalibor.topic at sun.com (dalibor.topic at sun.com)
Date: Fri, 30 Apr 2010 21:03:25 +0000
Subject: hg: jigsaw/jigsaw/jdk: Check if natcmd directory exists before use
Message-ID: <20100430210337.BD7B34458F@hg.openjdk.java.net>

Changeset: 66cf4275f76e
Author:    robilad
Date:      2010-04-30 23:02 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/66cf4275f76e

Check if natcmd directory exists before use

! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
! test/org/openjdk/jigsaw/cli/JpkgArgsTest.java



From Dalibor.Topic at Sun.COM  Fri Apr 30 14:08:44 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 30 Apr 2010 23:08:44 +0200
Subject: make jpkg resource path absolute
In-Reply-To: <20100430203300.20B1A3AD@eggemoggin.niobe.net>
References: <20100430203300.20B1A3AD@eggemoggin.niobe.net>
Message-ID: <4BDB46DC.3030003@sun.com>

Mark Reinhold wrote:
>> Date: Fri, 30 Apr 2010 13:27:04 -0700
>> From: akhil.arora at oracle.com
> 
>> On 04/30/2010 01:25 PM, Mark Reinhold wrote:
>>> Are you saying that if you pass an absolute path to -r then it's not
>>> interpreted as absolute?  That would be a bug.
>> An absolute path passed to -r is not accepted at all - jpkg insists on being
>> given a relative path for -r.
> 
> Yow, that's even worse!  Definitely a bug.

Yeah - I'll have a fix for it soon.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: J?rgen Kunz




From dalibor.topic at sun.com  Fri Apr 30 14:23:16 2010
From: dalibor.topic at sun.com (dalibor.topic at sun.com)
Date: Fri, 30 Apr 2010 21:23:16 +0000
Subject: hg: jigsaw/jigsaw/jdk: Check if config directory exists before use
Message-ID: <20100430212328.D96E44459B@hg.openjdk.java.net>

Changeset: 321a34dd0dc1
Author:    robilad
Date:      2010-04-30 23:22 +0200
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/321a34dd0dc1

Check if config directory exists before use

! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
! test/org/openjdk/jigsaw/cli/JpkgArgsTest.java