hg: jigsaw/jake/langtools: 8159607: Update javadoc to support annotations on module-info.java

[jonathan . gibbons]

Changeset: 7678462efbc3
Author:bpatel
Date:  2016-11-23 15:29 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7678462efbc3

8159607: Update javadoc to support annotations on module-info.java
Reviewed-by: jjg

! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/jdk/javadoc/doclet/testModules/module2/module-info.java
+ test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationType.java
+ 
test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/AnnotationTypeUndocumented.java

hg: jigsaw/jake/langtools: 8168766: javadoc should support deprecation on modules.

[jonathan . gibbons]

Changeset: 98a2842ec26a
Author:bpatel
Date:  2016-11-23 14:01 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/98a2842ec26a

8168766: javadoc should support deprecation on modules.
Reviewed-by: jjg

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java
! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/jdk/javadoc/doclet/testModules/module1/module-info.java
! test/jdk/javadoc/doclet/testModules/module2/module-info.java
! test/jdk/javadoc/doclet/testModules/moduletags/module-info.java

Re: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory

[Mandy Chung]

> On Nov 23, 2016, at 6:05 AM, Alan Bateman  wrote:
> 
> 
> 
> On 22/11/2016 21:07, Mandy Chung wrote:
>> This patch moves src.zip and jrt-fs.jar from the top-level into
>> the `lib` directory in the run-time image as we proposed [1].
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/
>> 
>> 
> This looks good. A minor point in SystemImage.findHome is that it's probably 
> an InternalError if we are somehow loaded from a jrt-fs.jar that is not in 
> the lib directory.

Agree.  The existing check if non “file” URL should also throw InternalError 
instead.  Fixed.

@@ -113,12 +113,16 @@
 if (cs == null)
 return System.getProperty("java.home");
 
-// assume loaded from $TARGETJDK/jrt-fs.jar
+// assume loaded from $TARGETJDK/lib/jrt-fs.jar
 URL url = cs.getLocation();
 if (!url.getProtocol().equalsIgnoreCase("file"))
-throw new RuntimeException(url + " loaded in unexpected way");
+throw new InternalError(url + " loaded in unexpected way");
 try {
-return Paths.get(url.toURI()).getParent().toString();
+Path lib = Paths.get(url.toURI()).getParent();
+if (!lib.getFileName().toString().equals("lib"))
+throw new InternalError(url + " unexpected path");
+
+return lib.getParent().toString();
 } catch (URISyntaxException e) {
 throw new InternalError(e);
 }

Mandy

hg: jigsaw/jake/langtools: Adjusting attribute name.

[jan . lahoda]

Changeset: 12008d1dd118
Author:jlahoda
Date:  2016-11-23 16:45 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/12008d1dd118

Adjusting attribute name.

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

Re: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory

[Alan Bateman]

On 22/11/2016 21:07, Mandy Chung wrote:

This patch moves src.zip and jrt-fs.jar from the top-level into
the `lib` directory in the run-time image as we proposed [1].

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/


This looks good. A minor point in SystemImage.findHome is that it's 
probably an InternalError if we are somehow loaded from a jrt-fs.jar 
that is not in the lib directory.


-Alan

Re: Moving the changes in jake to jdk9/dev

[Alan Bateman]

On 23/11/2016 13:36, Remi Forax wrote:


Hi Alan,
With my ASM hat,
we've planned to make a new beta of ASM as soon as the module class file format 
patches are merged into jdk9 :)

Great. One thing that we've had to do in the JDK copy of ASM is update 
ClassWriter.visit to be able to take a null name (#ClassFileModuleName 
issue where this_class is 0). That is probably something that the update 
beta should handle for those using it to create a module-info.class.


-Alan

Re: Moving the changes in jake to jdk9/dev

[Remi Forax]

Hi Alan,
With my ASM hat,
we've planned to make a new beta of ASM as soon as the module class file format 
patches are merged into jdk9 :)

Rémi

- Mail original -
> De: "Alan Bateman" 
> À: "jigsaw-dev" 
> Envoyé: Mercredi 23 Novembre 2016 12:55:11
> Objet: Moving the changes in jake to jdk9/dev

> We've been accumulating changes in the jake forest that are tied to JSR
> issues for the last few months. Some of the changes (such as
> #ClassLoaderNames) have already been pushed upstream to jdk9/dev but
> we've still sitting on a large patch.
> 
> We would like to move the changes that we have in jake to jdk9/dev soon,
> early December if possible. One motivation is to get the changes and new
> APIs into JDK 9 main line so that they can be used and tested more
> widely. This should help reduce some of the confusion with having two
> builds too. Another motivation is that the merging is getting painful,
> esp. the langtools repository where we have regular conflicts with
> changes to javac pushed via jdk9/dev.
> 
> To that end, I will start a code review soon that will be a snapshot of
> the changes in the jake forest. Once these changes are reviewed and in
> jdk9/dev then we will continue in the jake forest where appropriate -
> particularly in areas that are tied to JSR issues where we need to
> iterate and prototype, also in areas where we need to re-work some areas
> of the implementation.
> 
> As people on this mailing list know, jake has the changes for
> #AwkwardStrongEncapsulation [1] where setAccessible has been changed so
> it can't be used to break into non-public members/types in exported
> packages of JDK modules. It was changed more than a year ago to fail
> when attempting to use it to break into non-exported packages. Dialing
> it up further is a disruptive change that will expose a lot of hacks and
> issues with existing code that is used to accessing non-public
> fields/methods in JDK classes. It will take some libraries and tools a
> bit of time to digest this change, even with the --add-opens command
> line option and Add-Opens manifest in application JAR files to keep
> existing code going. I plan to send mail to jdk9-dev in advance of this
> integration to create wider awareness of this change.
> 
> -Alan
> 
> [1]
> http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation

hg: jigsaw/jake/jdk: Rename new attributes to ModuleXXX

[alan . bateman]

Changeset: 6c9428da24a4
Author:alanb
Date:  2016-11-23 13:32 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c9428da24a4

Rename new attributes to ModuleXXX

! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties
! src/java.base/share/classes/java/lang/module/ModuleInfo.java
! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java
! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
! test/java/lang/reflect/Module/AnnotationsTest.java
! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java

hg: jigsaw/jake/langtools: Rename new attributes to ModuleXXX

[alan . bateman]

Changeset: f3be37a11045
Author:alanb
Date:  2016-11-23 13:32 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f3be37a11045

Rename new attributes to ModuleXXX

! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java
- src/jdk.jdeps/share/classes/com/sun/tools/classfile/Hashes_attribute.java
- src/jdk.jdeps/share/classes/com/sun/tools/classfile/MainClass_attribute.java
+ 
src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleHashes_attribute.java
+ 
src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleMainClass_attribute.java
+ 
src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModulePackages_attribute.java
+ 
src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleTarget_attribute.java
+ 
src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleVersion_attribute.java
- src/jdk.jdeps/share/classes/com/sun/tools/classfile/Packages_attribute.java
- 
src/jdk.jdeps/share/classes/com/sun/tools/classfile/TargetPlatform_attribute.java
- src/jdk.jdeps/share/classes/com/sun/tools/classfile/Version_attribute.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
! test/lib/annotations/annotations/classfile/ClassfileInspector.java
! test/tools/javac/MethodParameters/AttributeVisitor.java

Moving the changes in jake to jdk9/dev

[Alan Bateman]

We've been accumulating changes in the jake forest that are tied to JSR 
issues for the last few months. Some of the changes (such as 
#ClassLoaderNames) have already been pushed upstream to jdk9/dev but 
we've still sitting on a large patch.


We would like to move the changes that we have in jake to jdk9/dev soon, 
early December if possible. One motivation is to get the changes and new 
APIs into JDK 9 main line so that they can be used and tested more 
widely. This should help reduce some of the confusion with having two 
builds too. Another motivation is that the merging is getting painful, 
esp. the langtools repository where we have regular conflicts with 
changes to javac pushed via jdk9/dev.


To that end, I will start a code review soon that will be a snapshot of 
the changes in the jake forest. Once these changes are reviewed and in 
jdk9/dev then we will continue in the jake forest where appropriate - 
particularly in areas that are tied to JSR issues where we need to 
iterate and prototype, also in areas where we need to re-work some areas 
of the implementation.


As people on this mailing list know, jake has the changes for 
#AwkwardStrongEncapsulation [1] where setAccessible has been changed so 
it can't be used to break into non-public members/types in exported 
packages of JDK modules. It was changed more than a year ago to fail 
when attempting to use it to break into non-exported packages. Dialing 
it up further is a disruptive change that will expose a lot of hacks and 
issues with existing code that is used to accessing non-public 
fields/methods in JDK classes. It will take some libraries and tools a 
bit of time to digest this change, even with the --add-opens command 
line option and Add-Opens manifest in application JAR files to keep 
existing code going. I plan to send mail to jdk9-dev in advance of this 
integration to create wider awareness of this change.


-Alan

[1] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation

Re: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory

[Erik Joelsson]

Build changes look good.

/Erik

On 2016-11-22 22:07, Mandy Chung wrote:

This patch moves src.zip and jrt-fs.jar from the top-level into
the `lib` directory in the run-time image as we proposed [1].

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/

thanks
Mandy
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html

hg: jigsaw/jake/jdk: Replace exported-private with open

[chris . hegarty]

Changeset: 3750898360d0
Author:chegar
Date:  2016-11-23 09:55 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3750898360d0

Replace exported-private with open

! src/java.base/share/classes/java/lang/Class.java