hg: jigsaw/jake: Post-process step to create jmod files

[mandy . chung]

Changeset: 80abe3cb308c
Author:mchung
Date:  2013-09-10 11:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/80abe3cb308c

Post-process step to create jmod files

! common/makefiles/Main.gmk

Re: RFR 8058117: Missing jdk.deploy.osx from modules.xml

[Mandy Chung]

On 9/10/2014 8:43 AM, Chris Hegarty wrote:
While looking at the parsing of modules.xml, I came across a potential 
issue; jdk.deploy.osx is not listed in modules.xml. This was just an 
oversight in the original generation of modules.xml, as it will only 
appear on Mac.




Looks okay.  Thanks for catching it and the fix.

Mandy

Note: This is not an issue for the build as jdk.deploy.osx is in 
modules.list


Trivial patch:

diff --git a/modules.xml b/modules.xml
--- a/modules.xml
+++ b/modules.xml
@@ -1569,6 +1569,12 @@
 dependjdk.crypto.ec/depend
   /module
   module
+ namejdk.deploy.osx/name
+ dependjava.base/depend
+ dependjava.desktop/depend
+ dependjava.scripting/depend
+ /module
+ module
 namejdk.dev/name
 dependjava.base/depend
 dependjava.scripting/depend

-Chris.

hg: jigsaw/m2/langtools: Update jdeps to work with modular image

[mandy . chung]

Changeset: 11a11f331a42
Author:mchung
Date:  2014-09-24 12:16 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/11a11f331a42

Update jdeps to work with modular image

! src/jdk.dev/share/classes/com/sun/tools/jdeps/ClassFileReader.java
! src/jdk.dev/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java
! src/jdk.dev/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
! src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java
! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/Basic.java
! test/tools/jdeps/DotFileTest.java
- test/tools/jdeps/profiles.properties

hg: jigsaw/m2: 20 new changesets

[mandy . chung]

Changeset: 34df46455488
Author:lancea
Date:  2014-09-12 17:46 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/34df46455488

8058366: Export sun.misc to java.sql
Reviewed-by: mchung

! modules.xml

Changeset: a3ee36412163
Author:ehelin
Date:  2014-09-15 16:30 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/a3ee36412163

8058317: Top-level Makefiles uses deprecated target jvmg in HotSpot Makefiles
Reviewed-by: erikj, tbell

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: 96de7aa61b7e
Author:mchung
Date:  2014-09-15 12:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/96de7aa61b7e

8058367: Add verify-modules target to the default and images target
Reviewed-by: alanb, erikj, ihse, prr

! make/Main.gmk

Changeset: 980f315286b9
Author:erikj
Date:  2014-09-16 12:08 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/980f315286b9

8058118: Generate modules.list during the build
Reviewed-by: alanb, ihse, tbell, mchung

! Makefile
! common/autoconf/spec.gmk.in
! make/Main.gmk
! make/common/Modules.gmk
! make/common/SetupJavaCompilers.gmk
- make/common/modules.list
! modules.xml

Changeset: 33968ec4cc68
Author:erikj
Date:  2014-08-28 11:58 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/33968ec4cc68

8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
Reviewed-by: dholmes, ihse, dcubed

! common/autoconf/hotspot-spec.gmk.in
! make/HotspotWrapper.gmk

Changeset: fac17bf59030
Author:amurillo
Date:  2014-09-12 13:59 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/fac17bf59030

Merge


Changeset: 2556d0c2976a
Author:amurillo
Date:  2014-09-13 14:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/2556d0c2976a

Merge


Changeset: 1540bfaa0606
Author:amurillo
Date:  2014-09-16 08:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/1540bfaa0606

Merge


Changeset: d1d2ca914d49
Author:weijun
Date:  2014-09-17 13:55 +0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/d1d2ca914d49

8056141: Move com.sun.security.jgss into a new module
Reviewed-by: alanb, chegar, mchung

! common/bin/unshuffle_list.txt
! modules.xml

Changeset: 7e3512dae8e0
Author:lana
Date:  2014-09-18 13:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/7e3512dae8e0

Merge

- make/common/modules.list

Changeset: 0937ce5890bc
Author:erikj
Date:  2014-09-19 11:53 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/0937ce5890bc

8058797: Building with sjavac broken after JDK-8058118
Reviewed-by: ihse

! make/common/JavaCompilation.gmk
! make/common/Modules.gmk

Changeset: d289c41136b9
Author:erikj
Date:  2014-09-23 07:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/d289c41136b9

8047933: Race between jdk/make/scripts/genExceptions.sh and 
com.sun.tools.javadoc.Main
Reviewed-by: ihse, tbell

! make/Main.gmk

Changeset: 7feeff170f81
Author:tbell
Date:  2014-09-23 07:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/7feeff170f81

Merge

! make/Main.gmk
- make/common/modules.list

Changeset: 654b0f026152
Author:igerasim
Date:  2014-09-25 21:16 +0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/654b0f026152

8059101: unshuffle_patch.sh should be able to deal with stdin/stdout
Reviewed-by: dfuchs, chegar

! common/bin/unshuffle_patch.sh

Changeset: 924b0ce4a167
Author:prr
Date:  2014-09-19 09:42 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/924b0ce4a167

8056216: Remove sun directory layer from libawt and common
Reviewed-by: erikj, ihse, coffeys

! common/bin/unshuffle_list.txt

Changeset: ee6759334331
Author:prr
Date:  2014-09-19 11:19 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/ee6759334331

Merge

! common/bin/unshuffle_list.txt
- make/common/modules.list

Changeset: 555f3152c254
Author:prr
Date:  2014-09-25 14:17 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/555f3152c254

Merge


Changeset: e1e5dd0de2e8
Author:katleman
Date:  2014-09-25 12:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/e1e5dd0de2e8

Added tag jdk9-b32 for changeset 7e3512dae8e0

! .hgtags

Changeset: e4ba01b726e2
Author:lana
Date:  2014-09-25 16:19 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/e4ba01b726e2

Merge


Changeset: edb718e7ad89
Author:mchung
Date:  2014-09-27 00:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/edb718e7ad89

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! make/Main.gmk
! make/common/JavaCompilation.gmk
! make/common/Modules.gmk
- make/common/modules.list
! modules.xml

hg: jigsaw/m2/corba: 4 new changesets

[mandy . chung]

Changeset: cfdac5887952
Author:katleman
Date:  2014-09-25 12:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/corba/rev/cfdac5887952

Added tag jdk9-b32 for changeset b5b139354630

! .hgtags

Changeset: 1683040fc3fa
Author:mchung
Date:  2014-09-27 00:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/corba/rev/1683040fc3fa

Merge


Changeset: 0e38044a6f85
Author:alanb
Date:  2014-09-26 22:24 +0100
URL:   http://hg.openjdk.java.net/jigsaw/m2/corba/rev/0e38044a6f85

8049389: Move orb.idl and ir.idl to JDK include directory
Reviewed-by: erikj

! make/CompileCorba.gmk

Changeset: 510cfe347afd
Author:mchung
Date:  2014-09-27 08:30 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/corba/rev/510cfe347afd

Merge

! make/CompileInterim.gmk

hg: jigsaw/m2/jaxws: 6 new changesets

[mandy . chung]

Changeset: d35ad0854f68
Author:mkos
Date:  2014-09-12 17:20 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxws/rev/d35ad0854f68

8054548: JAX-WS tools need to updated to work with modular image
Summary: Removing java reflection API to get JavaCompiler; using standard 
javax.tools API instead
Reviewed-by: alanb

- 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ApClassLoader.java
- 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/Invoker.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/WsGen.java
! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/WsImport.java
! 
src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/JavacompilerMessages.java
! 
src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/javacompiler.properties
! 
src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java

Changeset: 838a2f693e51
Author:lana
Date:  2014-09-18 13:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxws/rev/838a2f693e51

Merge

- 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ApClassLoader.java
- 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java

Changeset: ad01ed3c9ac2
Author:mkos
Date:  2014-09-25 10:02 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxws/rev/ad01ed3c9ac2

8038966: JAX-WS handles wrongly xsd:any arguments for Web services
Reviewed-by: coffeys

! 
src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/ContentHandlerAdaptor.java
! 
src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXStreamConnector.java

Changeset: 2c42a24c7d8c
Author:katleman
Date:  2014-09-25 12:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxws/rev/2c42a24c7d8c

Added tag jdk9-b32 for changeset 838a2f693e51

! .hgtags

Changeset: 77a45995dd3b
Author:lana
Date:  2014-09-25 16:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxws/rev/77a45995dd3b

Merge


Changeset: ba8a49ad62e2
Author:mchung
Date:  2014-09-27 00:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxws/rev/ba8a49ad62e2

Merge

- 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ApClassLoader.java
- 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java

hg: jigsaw/m2/hotspot: 70 new changesets

[mandy . chung]

Changeset: 6818c5298fab
Author:dholmes
Date:  2014-09-02 21:27 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/6818c5298fab

8046210: Missing memory barrier when reading init_lock
Reviewed-by: fparain, dcubed, mdoerr
Contributed-by: Bill Pittore bill.pitt...@oracle.com

! src/share/vm/oops/instanceKlass.cpp

Changeset: 20c8773305b1
Author:sla
Date:  2014-09-03 14:43 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/20c8773305b1

8056242: Add function to return structured information about loaded libraries.
Summary: Return structured information about loaded libraries.
Reviewed-by: sla, dsamersoff
Contributed-by: fredrik.arvids...@oracle.com

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp

Changeset: e3fb51ae8d7d
Author:coleenp
Date:  2014-09-03 19:13 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/e3fb51ae8d7d

8055008: Clean up code that saves the previous versions of redefined classes
Summary: Use scratch_class to find EMCP methods for breakpoints if the old 
methods are still running.
Reviewed-by: dcubed, sspitsyn

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/classfile/metadataOnStackMark.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/method.hpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
- test/runtime/RedefineFinalizer/RedefineFinalizer.java
+ test/runtime/RedefineTests/RedefineFinalizer.java
+ test/runtime/RedefineTests/RedefineRunningMethods.java

Changeset: 0c68d517f7ec
Author:sla
Date:  2014-09-04 08:48 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/0c68d517f7ec

Merge

- test/runtime/RedefineFinalizer/RedefineFinalizer.java

Changeset: c770a9cc2f86
Author:dsamersoff
Date:  2014-09-04 04:17 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/c770a9cc2f86

8035419: warning from b09 for hotspot.agent.src.os.win32.windbg.sawindbg.cpp: 
'JNI exception pending'
Summary: added missed exceptions checks
Reviewed-by: sla, sspitsyn

! agent/src/os/win32/windbg/sawindbg.cpp

Changeset: 86bbebf1b7bf
Author:zgu
Date:  2014-09-04 14:50 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/86bbebf1b7bf

8055289: Internal Error: mallocTracker.cpp:146 fatal error: Should not use 
malloc for big memory block, use virtual memory instead
Summary: Return NULL if memory allocation size is bigger than MAX_MALLOC_SIZE 
when NMT is on
Reviewed-by: coleenp, gtriantafill

! src/share/vm/runtime/os.cpp
! test/TEST.groups
+ test/runtime/NMT/UnsafeMallocLimit.java

Changeset: 7bf26f6f8d41
Author:zgu
Date:  2014-09-04 14:58 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/7bf26f6f8d41

Merge

- 
agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java
- src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
- src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
- src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp
- test/runtime/RedefineFinalizer/RedefineFinalizer.java

Changeset: 479ed4234a9d
Author:coleenp
Date:  2014-09-05 08:08 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/479ed4234a9d

8057570: RedefineClasses() tests fail assert(((Metadata*)obj)-is_valid()) 
failed: obj is valid
Summary: Revert two small changes from the previous-versions cleanup with 
marking code cache.
Reviewed-by: kvn, dcubed

! src/share/vm/code/nmethod.cpp
! src/share/vm/memory/universe.cpp

Changeset: 08e071425343
Author:iklam
Date:  2014-09-05 15:53 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/08e071425343

Merge

! src/share/vm/classfile/classLoaderData.cpp
- test/compiler/intrinsics/mathexact/sanity/Verifier.java

Changeset: d2f2777ac502
Author:erikj
Date:  2014-08-28 11:59 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/d2f2777ac502

8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
Reviewed-by: dholmes, ihse, dcubed

! make/Makefile
! make/aix/Makefile
! make/aix/makefiles/buildtree.make
! make/aix/makefiles/top.make
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/top.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/top.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/top.make

Changeset: aff33974bb53
Author:coleenp
Date:  2014-09-08 11:14 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/aff33974bb53

8057696: java -version triggers assertion for slowdebug zero builds
Summary: The change as introduced with JDK-8003426 removed some zero code in 

hg: jigsaw/m2/jaxp: 2 new changesets

[mandy . chung]

Changeset: 46b360454dad
Author:katleman
Date:  2014-09-25 12:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxp/rev/46b360454dad

Added tag jdk9-b32 for changeset b940ca3d2c7e

! .hgtags

Changeset: bf5a6fa4e8c2
Author:mchung
Date:  2014-09-27 00:40 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jaxp/rev/bf5a6fa4e8c2

Merge

hg: jigsaw/m2/langtools: 15 new changesets

[mandy . chung]

Changeset: 3eb8614e39b3
Author:sogoel
Date:  2014-09-12 17:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/3eb8614e39b3

8055080: Group 9d: golden files for tests in tools/javac dir
Reviewed-by: jjg, mcimadamore, jlahoda

! test/tools/javac/Parens1.java
+ test/tools/javac/Parens1.out
! test/tools/javac/Parens2.java
+ test/tools/javac/Parens2.out
! test/tools/javac/Parens3.java
+ test/tools/javac/Parens3.out
! test/tools/javac/Parens4.java
+ test/tools/javac/Parens4.out
! test/tools/javac/ParseConditional.java
+ test/tools/javac/ParseConditional.out
! test/tools/javac/StoreClass.java
+ test/tools/javac/StoreClass.out
! test/tools/javac/SwitchScope.java
+ test/tools/javac/SwitchScope.out
! test/tools/javac/SynthName2.java
+ test/tools/javac/SynthName2.out
! test/tools/javac/T6234077.java
+ test/tools/javac/T6234077.out

Changeset: c419bddef7f3
Author:mcimadamore
Date:  2014-09-15 12:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/c419bddef7f3

8055963: Inference failure with nested invocation
Summary: Revise heuristics to force eager instantiation of return inference vars
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/generics/inference/8055963/T8055963.java

Changeset: 9a6c1bf0d19a
Author:bpatel
Date:  2014-09-17 23:52 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/9a6c1bf0d19a

8043698: title tag not getting generated in package-summary pages for 
un-named packages
Reviewed-by: jjg, ksrini

! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java

Changeset: 7e15b8d4631d
Author:bpatel
Date:  2014-09-18 00:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/7e15b8d4631d

8047745: Javadoc should include encoding information in generated html files
Reviewed-by: jjg, ksrini

! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! test/com/sun/javadoc/testCharset/TestCharset.java

Changeset: ad99965443d1
Author:lana
Date:  2014-09-18 13:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/ad99965443d1

Merge


Changeset: c67dc7a385b2
Author:sogoel
Date:  2014-09-19 13:54 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/c67dc7a385b2

8058755: Update tools/javadoc/6227454 to add head tag
Reviewed-by: jjg

! test/tools/javadoc/6227454/Test.java

Changeset: 2f8f2ae8a806
Author:jlahoda
Date:  2014-09-22 14:55 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/2f8f2ae8a806

8057794: Compiler Error when obtaining .class property
Summary: Ensuring a non-null type and sym for illegal T.class to prevent 
downstream errors.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/T8057794.java
+ test/tools/javac/lambda/T8057794.out

Changeset: ff1998c1ecab
Author:emc
Date:  2014-09-22 17:09 -0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/ff1998c1ecab

8048614: Add TypeMetadata to contain type annotations and other type information
Summary: Implement general framework for metadata on types
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
+ src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeMetadata.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/UninitializedType.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacTypes.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/types/TypeHarness.java

Changeset: 3c7c7485fab7
Author:ntoda
Date:  2014-09-25 13:54 -0700
URL:   

hg: jigsaw/m2/nashorn: 19 new changesets

[mandy . chung]

Changeset: a20309596c42
Author:hannesw
Date:  2014-09-12 11:00 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/a20309596c42

8057743: Single quotes must be escaped in message resource file
Reviewed-by: attila, lagergren, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties
! test/script/basic/JDK-8043232.js.EXPECTED
! test/script/basic/JDK-8049242.js.EXPECTED

Changeset: ec55eed621a8
Author:hannesw
Date:  2014-09-12 15:01 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/ec55eed621a8

8058304: Non-serializable fields in serializable classes
Reviewed-by: lagergren, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java

Changeset: e86dd06a8ccb
Author:sundar
Date:  2014-09-15 15:18 +0530
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/e86dd06a8ccb

8058422: Users should be able to overwrite context and engine variables
Reviewed-by: lagergren, attila

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
+ test/script/basic/JDK-8058422.js
! test/src/jdk/nashorn/api/scripting/ScopeTest.java

Changeset: 10f36ba5ef80
Author:hannesw
Date:  2014-09-15 17:51 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/10f36ba5ef80

8056978: ClassCastException: cannot cast jdk.nashorn.internal.scripts.JO*
Reviewed-by: jlaskey, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FieldObjectCreator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyMap.java
+ test/script/basic/JDK-8056978.js
+ test/script/basic/JDK-8056978.js.EXPECTED

Changeset: 3936203c7dc8
Author:sundar
Date:  2014-09-16 17:04 +0530
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/3936203c7dc8

8058545: With strict mode, bean property assignment of a non-existent property 
should result in TypeError
Reviewed-by: hannesw, lagergren

! README
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
+ test/script/basic/JDK-8058545.js

Changeset: 9f8ab1b79632
Author:sundar
Date:  2014-09-16 17:47 +0530
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/9f8ab1b79632

8058551: Top level README accidentally modified with changeset 1025:3936203c7dc8
Reviewed-by: jlaskey, hannesw

! README

Changeset: fbded97d28ca
Author:sundar
Date:  2014-09-17 15:02 +0530
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/fbded97d28ca

8058615: Overload resolution ambiguity involving ConsString
Reviewed-by: lagergren, hannesw

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
+ test/script/basic/JDK-8058615.js
+ test/script/basic/JDK-8058615.js.EXPECTED

Changeset: f2771da9af07
Author:yan
Date:  2014-09-17 16:44 +0400
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/f2771da9af07

8057035: Some tests failed using java.awt.Color on Solaris without X11 libraries
Reviewed-by: lagergren
Contributed-by: Sergey Lugovoy sergey.lugo...@oracle.com

! test/script/basic/JDK-8043232.js
! test/script/basic/JDK-8043232.js.EXPECTED
! test/script/basic/JDK-8049086.js
! test/script/basic/JDK-8049086.js.EXPECTED
! test/script/basic/JDK-8049242.js
! test/script/basic/JDK-8049242.js.EXPECTED

Changeset: 62ba20541b94
Author:lana
Date:  2014-09-18 13:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/62ba20541b94

Merge


Changeset: 52752e15fe18
Author:hannesw
Date:  2014-09-19 13:13 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/52752e15fe18

8046202: Make persistent code store more flexible
Reviewed-by: lagergren, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FunctionInitializer.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StoredScript.java

Changeset: c1f651636d9c
Author:hannesw
Date:  2014-09-22 13:28 +0200
URL:   http://hg.openjdk.java.net/jigsaw/m2/nashorn/rev/c1f651636d9c

8047764: Indexed or polymorphic set on global affects Object.prototype
Reviewed-by: lagergren, attila

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
! 

Review Request: JDK-8059083: Remove jdk.compact3 from modules.xml

[Mandy Chung]

jdk.compact3 was meant to be removed when we integrated JEP 201:

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

Mandy

Re: RFR 8046002: Move Ucrypto to the open jdk repo

[Mandy Chung]

On 10/15/14 3:20 PM, Valerie Peng wrote:

Hi, experts,

Please review the update for module.xml for 8046002: Move Ucrypto to 
the open jdk repo


http://cr.openjdk.java.net/~valeriep/8046002_top/webrev.00/


Looks okay to me too.

Mandy

hg: jigsaw/m2/jdk: 8059315: KeyStore and keytool tests failing with KeyStoreException; ...

[mandy . chung]

Changeset: d359a9bb2d3a
Author:mchung
Date:  2014-10-17 12:16 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/d359a9bb2d3a

8059315: KeyStore and keytool tests failing with KeyStoreException
8059316: closed/com/sun/crypto/provider/KeyStore/BackwardCompatibility.java 
failing in jigsaw/m2

! src/java.base/share/classes/javax/crypto/JceSecurityManager.java
! src/java.base/share/classes/javax/crypto/ProviderVerifier.java

hg: jigsaw/m2/langtools: Remove jdeps legacy image support

[mandy . chung]

Changeset: 604f4be5fcea
Author:mchung
Date:  2014-10-20 19:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/604f4be5fcea

Remove jdeps legacy image support

! src/jdk.dev/share/classes/com/sun/tools/jdeps/Archive.java
! src/jdk.dev/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/jdk.dev/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
! src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java

hg: jigsaw/m2/jdk: jfxrt.jar moved from lib/ext to lib in the modular image

[mandy . chung]

Changeset: ca389ce52206
Author:mchung
Date:  2014-10-21 11:53 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/ca389ce52206

jfxrt.jar moved from lib/ext to lib in the modular image

! src/java.base/share/classes/sun/misc/Launcher.java

hg: jigsaw/m2/langtools: jfxrt.jar moved from lib/ext to lib in the modular image

[mandy . chung]

Changeset: 8dd333dfc21c
Author:mchung
Date:  2014-10-21 11:53 -0700
URL:   http://hg.openjdk.java.net/jigsaw/m2/langtools/rev/8dd333dfc21c

jfxrt.jar moved from lib/ext to lib in the modular image

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java

Re: CFV: New Jigsaw Committer: Sundar Athijegannathan

[Mandy Chung]

Vote: yes

On 11/3/14 6:02 AM, Alan Bateman wrote:

I hereby nominate Sundar Athijegannathan to Jigsaw Committer.

Sundar is currently a Reviewer on the jdk9,  jdk8u and Nashorn 
projects. Sundar has been contributing to Project Jigsaw by way of the 
compression support in jimage container format and also the file 
system provider implementation, both of which are prototyped in the 
jigsaw/m2 forest.


Votes are due by: Nov 17, 2014, 07.00 PST. Only current Jigsaw 
Committers [1] are eligible to vote on this nomination. Votes must be 
cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2].

-Alan.

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

hg: jigsaw/m2/hotspot: Replace PrintExtDirsWarning with -XX:+CheckEndorsedAndExtDirs flag

[mandy . chung]

Changeset: 9531206c79a6
Author:mchung
Date:  2014-11-10 12:05 -0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/hotspot/rev/9531206c79a6

Replace PrintExtDirsWarning with -XX:+CheckEndorsedAndExtDirs flag

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

hg: jigsaw/m2/jdk: 8064782: Change jdeps to use jrt:/ instead of jimagefs

[mandy . chung]

Changeset: 8cb493f1bb25
Author:mchung
Date:  2014-11-17 19:18 -0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/8cb493f1bb25

8064782: Change jdeps to use jrt:/ instead of jimagefs

! make/src/classes/build/tools/module/ModulesXmlReader.java
! make/src/classes/build/tools/module/ModulesXmlWriter.java

hg: jigsaw/m2: ucrypto moved to the open

[mandy . chung]

Changeset: 7ec2be25e81e
Author:mchung
Date:  2014-11-17 19:52 -0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/7ec2be25e81e

ucrypto moved to the open

! make/Images.gmk

hg: jigsaw/m2/jdk: Remove @Deprecated from EXTENSION_NAME and EXTENSION_LIST

[mandy . chung]

Changeset: 3e198fd8bac3
Author:mchung
Date:  2014-11-26 08:32 -0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/3e198fd8bac3

Remove @Deprecated from EXTENSION_NAME and EXTENSION_LIST

! src/java.base/share/classes/java/util/jar/Attributes.java

Re: Review request 8069551: Move java.security.acl from compact3 to java.base

[Mandy Chung]

On 1/30/15 12:50 AM, Alan Bateman wrote:

On 29/01/2015 20:58, Mandy Chung wrote:

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

java.security.acl is superceded by java.security package since 1.2.

This patch proposes to move java.security.acl package to java.base 
module rather than complicating the module graph with a 
close-to-useless dedicated module.
This looks okay. One small suggestion is to move the lines in 
unshuffle_list.txt up to where the other java.base paths are.


Yes that's better. Fixed.

thanks.
Mandy

Review request: JDK-8069414: Rename oracle.accessbridge to jdk.accessbridge

[Mandy Chung]

diff --git a/modules.xml b/modules.xml
--- a/modules.xml
+++ b/modules.xml
@@ -737,7 +737,7 @@
 /export
 export
   namesun.awt/name
-  tooracle.accessbridge/to
+  tojdk.accessbridge/to
 /export
   /module
   module

Mandy

Re: Apache Maven JDeps Plugin

[Mandy Chung]

Hi Robert,

Indeed this looks very useful.

On 2/16/2015 10:45 AM, Alan Bateman wrote:

On 16/02/2015 18:28, Robert Scholte wrote:

Hi Alan,

if you are referring to the -R / -recursive option of the jdeps tool, 
then yes you can.
See 
http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/jdkinternals-mojo.html#recursive
I think jdeps is first of all interesting for the classes of the 
current Java project, so I've set the default of this parameter to 
'false'. However, if the majority thinks it is better to activate 
this by default, we will consider to change this value.
I could imagine wanting to run it twice: once for the current project 
where I want the build to fail if it makes direct use of JDK-internal 
APIs, and a second time to run with -R and emit warnings if any of the 
transitive dependences (that I don't control) are using JDK internal 
APIs.


Another alternative to running jdeps -R, the plugin can run jdeps on all 
of the transitive dependences of the current project (all JAR files can 
be put in one jdeps command) that will find out if any of its 
dependences (analyze all classes) is using JDK internal API.


jdeps -R will only analyze classes that are referenced from the root set 
(i.e. the arguments passed to jdeps that I assume be the current 
project) and doesn't analyze any class in the dependences that is not 
referenced transitively.


The default is to run jdeps on the current project sounds reasonable to me.

Mandy

Re: [9] Review Request: 8072663: Remove the sun.security.acl package which is not used in the JDK

[Mandy Chung]

On 2/17/15 12:59 PM, Jason Uh wrote:

Please review this fix, which removes the sun.security.acl package.

webrev: http://cr.openjdk.java.net/~juh/8072663/00/
jbs: http://bugs.openjdk.java.net/browse/JDK-8072663


Looks fine.  While the java.security.acl package is small, it'd be nice 
if this package will be gone in a future release.


Mandy

Re: Apache Maven JDeps Plugin

[Mandy Chung]

Thanks I'll check it out.
Mandy

On 2/19/2015 12:10 PM, Robert Scholte wrote:

Hi Mandy,

based on your proposal I've added 2 parameters: 
dependenciesToAnalyzeIncludes and dependenciesToAnalyzeExcludes
This way it's not an All-Or-Nothing option, but instead you have full 
control over the dependencies to include.
You can select the dependencies by using the pattern 
groupId:artifactId in combination with '*'.


Some configuration examples:
This will select all dependencies for the specified scope (compile or 
test, depending on the goal)

  dependenciesToAnalyzeIncludes
 include*:*/include
  /dependenciesToAnalyzeIncludes

Here are some other patterns, which are allowed
  dependenciesToAnalyzeIncludes
 includeorg.foo.*:*/include
 includecom.foo.bar:*/include
 includedot.foo.bar:utilities/include
   /dependenciesToAnalyzeIncludes

With dependenciesToAnalyzeExcludes you can exclude a subset of 
dependenciesToAnalyzeIncludes.


  dependenciesToAnalyzeExcludes
 excludeorg.foo.test:*/exclude
  /dependenciesToAnalyzeExcludes

This should match your requirements.

Regards,
Robert Scholte


Op Wed, 18 Feb 2015 05:46:37 +0100 schreef Mandy Chung
mandy.ch...@oracle.com:


Hi Robert,

Indeed this looks very useful.

On 2/16/2015 10:45 AM, Alan Bateman wrote:

On 16/02/2015 18:28, Robert Scholte wrote:

Hi Alan,

if you are referring to the -R / -recursive option of the jdeps 
tool, then yes you can.
See 
http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/jdkinternals-mojo.html#recursive
I think jdeps is first of all interesting for the classes of the 
current Java project, so I've set the default of this parameter to 
'false'. However, if the majority thinks it is better to activate 
this by default, we will consider to change this value.
I could imagine wanting to run it twice: once for the current 
project where I want the build to fail if it makes direct use of 
JDK-internal APIs, and a second time to run with -R and emit 
warnings if any of the transitive dependences (that I don't control) 
are using JDK internal APIs.


Another alternative to running jdeps -R, the plugin can run jdeps on 
all of the transitive dependences of the current project (all JAR 
files can be put in one jdeps command) that will find out if any of 
its dependences (analyze all classes) is using JDK internal API.


jdeps -R will only analyze classes that are referenced from the root 
set (i.e. the arguments passed to jdeps that I assume be the current 
project) and doesn't analyze any class in the dependences that is not 
referenced transitively.


The default is to run jdeps on the current project sounds reasonable 
to me.


Mandy

Re: 8067867: Subsume module java.xml.soap into module java.xml.ws

[Mandy Chung]

On 1/3/15 1:24 AM, Alan Bateman wrote:


There are a number of proposed updates to the module graph that we 
need reflected in the source code layout (and the module graph in JEP 
200 [1] will need to be refreshed too). JDK-8067867 tracks dropping 
the module java.xml.soap  and subsuming the API into the java.xml.ws 
module.


The webrevs with the proposed changes are here:
   http://cr.openjdk.java.net/~alanb/8067867/



This patch looks good to me.

Mandy

Re: Policy providers in Java 9

[Mandy Chung]

On 3/21/2015 5:12 AM, Peter Firmstone wrote:

Just wondering, with the removal of the extensions directory, what's the 
correct way of specifying a policy provider?

We currently have a number of nested policy providers that are loaded by the 
extension classloader.


Do you set the custom policy provider by setting -Dpolicy.provider
system property?

One suggested way is to put the providers on -classpath and loaded
by the application class loader.

There are some SPIs that need adjustment to support loading the
providers by the application class loader and the policy SPI
should also be updated in JDK 9.  I'm including the security lead
Sean Mullan to recommend other ways.

Mandy

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

[Mandy Chung]

This module contains both pack200 and unpack200 tools although it only 
contains the native implementation of unpacker.  Naming it as 
jdk.unpack200 would give an impression that it contains the unpacker 
only which isn't the case.


Like the API java.util.jar.Pack200 class, it's about Pack200 format and 
it has both Pack200.Packer and Pack200.Unpacker nested interfaces


jdk.pack200 represents the tools for Pack200 format that sounds fine to me.

Mandy

On 3/10/2015 10:23 AM, Kumar Srinivasan wrote:

The changes look ok to me, however I am wondering if the module
could be called jdk.unpack200 and not jdk.pack200 ? since it
contains only the unpacker, and the bin utilities are pack200 and
unpack200.

Kumar

On 3/4/2015 5:13 PM, Mandy Chung wrote:

As listed in an open issue in JEP 200:

The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any other module; these modules will eventually
be either renamed or refactored.

Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in
the JDK that are organized around its primary tool.  Such organization
is easy to name, document and understand. This patch proposes to
move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool,
jdk.policytool modules.

Overall Webrev that will be convenient to review the build change
and modules.xml change.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ 



Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ 



2. jar, jarsigner to jdk.jartool

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ 



3. policytool to jdk.policytool

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ 



There are remaining tools in jdk.dev that will be handled separately.
jdk.dev will disappear when all of the remaining tools find its home.

Mandy

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

[Mandy Chung]

On 3/4/2015 6:55 PM, Wang Weijun wrote:

I am about to introduce 2 APIs into jdk.dev so that people can call functions 
of keytool and jarsigner directly.


Are you referring to these 2 RFEs?
https://bugs.openjdk.java.net/browse/JDK-8056174
https://bugs.openjdk.java.net/browse/JDK-8058778

We have to see the details and webrev to comment on your
proposed jdk.security.tools and jdk.security.util modules.

There is no issue in keeping a CLI like keytool in java.base.
What is your concern?

policytool is a GUI app that depends on java.desktop module.
If you move jarsigner, policytool and keytool, this new module
would require java.desktop to be present to be used.

Mandy


So what I am suggesting is

- Create jdk.security.util
- Move jarsigner, policytool to jdk.security.util
- Create the new APIs in this module
- Move keytool to jdk.security.util, it's now in java.base but keytool is not 
part of Java SE spec (Of course, if that means keytool will be in JDK instead 
of JRE please stop. But will there will the name difference anymore? I am 
thinking of an installer like cygwin that you can choose anything except that 
java.base is checked grayed).

Or, we can break it into jdk.security.tools and jdk.security.util. Put the 
executables into tools and APIs into util.

--Max


On Mar 5, 2015, at 09:13, Mandy Chung mandy.ch...@oracle.com wrote:

As listed in an open issue in JEP 200:

The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any other module; these modules will eventually
be either renamed or refactored.

Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in
the JDK that are organized around its primary tool.  Such organization
is easy to name, document and understand. This patch proposes to
move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool,
jdk.policytool modules.

Overall Webrev that will be convenient to review the build change
and modules.xml change.
   
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/

Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/

2. jar, jarsigner to jdk.jartool

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/

3. policytool to jdk.policytool

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/

There are remaining tools in jdk.dev that will be handled separately.
jdk.dev will disappear when all of the remaining tools find its home.

Mandy

Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

[Mandy Chung]

As listed in an open issue in JEP 200:

The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any other module; these modules will eventually
be either renamed or refactored.

Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in
the JDK that are organized around its primary tool.  Such organization
is easy to name, document and understand. This patch proposes to
move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool,
jdk.policytool modules.

Overall Webrev that will be convenient to review the build change
and modules.xml change.
   
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/

Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/

2. jar, jarsigner to jdk.jartool

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/

3. policytool to jdk.policytool

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/

There are remaining tools in jdk.dev that will be handled separately.
jdk.dev will disappear when all of the remaining tools find its home.

Mandy

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

[Mandy Chung]

Max,

Since the new APIs you're working on are still in design phase, I think 
it's a bit early to discuss where these new APIs should be in.


Just one thing to say about the new JarSigner API from your webrev.   
com.sun.jarsigner is an existing exported package that you should 
consider whether the new APIs should be added there rather than a new 
package.  Anyway, we can discuss that when your work is further along.


For this review request, are you okay with this patch moving policytool 
and jarsigner tools to the new home?


Mandy
[1] 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/85b61f4eee66/src/jdk.dev/share/classes/com/sun/jarsigner/package-info.java


On 3/5/15 1:13 AM, Weijun Wang wrote:
There is no problem the new API be in a separate module. It is 
independent of keytool now.


Said that, I've been thinking about rewriting keytool to use this new 
API.


--Max

On 3/5/2015 16:23, Alan Bateman wrote:

On 05/03/2015 02:55, Wang Weijun wrote:

- Move keytool to jdk.security.util, it's now in java.base but keytool
is not part of Java SE spec (Of course, if that means keytool will be
in JDK instead of JRE please stop. But will there will the name
difference anymore? I am thinking of an installer like cygwin that you
can choose anything except that java.base is checked grayed).



The reason that keytool is in java.base is so that keys and certificates
can be managed on a small runtime. It's the same reason that it is in
our compact1 builds too. I wasn't aware of JDK-8058778 but it can't
result in java.base exporting a JDK-specific API.

-Alan

Review request 8069551: Move java.security.acl from compact3 to java.base

[Mandy Chung]

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

java.security.acl is superceded by java.security package since 1.2.

This patch proposes to move java.security.acl package to java.base 
module rather than complicating the module graph with a close-to-useless 
dedicated module.


Mandy

Re: OS X 1.9 ea jdeps

[Mandy Chung]

On 4/13/15 1:32 AM, Michael Hall wrote:

On Apr 13, 2015, at 2:32 AM, Alan Bateman alan.bate...@oracle.com wrote:


On 12/04/2015 17:57, Michael Hall wrote:

:

Not exactly sure what you mean.
But,

which java
/usr/bin/java

...


I think the issue is that the installation creates sym links in /usr/bin for 
most, but not all, of the tools/launchers. So if you have 
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands or 
/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/bin on your 
PATH, say after /usr/bin, then it would explain what you are seeing.

This seems to be correct. Although for some reason right now it appears to be 
the 1.8.0_40 release in PATH and this is what 'which jdeps' returns. (usr/bin 
in path prior to this).
So is the jdeps case to be considered not an error? Just something to be aware 
of if you use an early access?
Or is it something that should be corrected? It seems like you are supporting 
two different ways to accomplish the same thing, /usr/bin sym links or PATH 
updates. Doesn’t this make things a little more difficult to keep track of?


jdeps is not the only JDK tool not in /usr/bin. The sym links from
/usr/bin are not created by the JDK installer.

/usr/bin/j* are linked to
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands
probably part of OS install and I guess it's a snapshot of JDK 7
commands.

If a JDK tool is added or removed for a new version of JDK, it
won't be reflected in /usr/bin.  You may want to follow up your
question from macosx-port-dev mailing list.

Mandy

Re: jdeps command

[Mandy Chung]

On 04/30/2015 03:02 PM, Michael Hall wrote:

Please file a bug at http://bugreporter.apple.com asking for this command to 
be added to /usr/bin, and send me the bug ID. We can ensure that these stubs are in 
the base OS without any Apple Java being installed.

Thanks,
Mike Swingler
Apple Inc.


Thanks much Mike. I haven’t done one for a while but it seems to have gotten 
out there.
I still look to have one bug open actually. I was a little surprised to see 
Java still has a bugreporter slot for Java.

20770788
Bug report was submitted successfully.


One thing to say about JDK  tools: New tools may be added in any JDK 
release (e.g. jjs in another tool added in JDK 8) and existing tool may 
be removed (e.g. jhat [1]).  This should be taken into account.


Mandy
[1] http://openjdk.java.net/jeps/241

Re: jdeps command

[Mandy Chung]

On 04/30/2015 04:17 PM, Michael Hall wrote:
On Apr 30, 2015, at 5:39 PM, Mandy Chung mandy.ch...@oracle.com 
mailto:mandy.ch...@oracle.com wrote:


and existing tool may be removed (e.g. jhat [1]). 


Not through Java 9 ea?

jhat -version
jhat version 2.0 (java version 1.9.0-ea)

So I would think it might be a little premature for Mike to remove the 
link on this one?




Right - things may change during JDK 9 development and should wait until 
GA.  My main point is that the list of JDK tools could be different for 
any release.


Mandy

Re: internal API usage: sun.awt.CausedFocusEvent

[Mandy Chung]

 On May 13, 2015, at 10:51 AM, Alan Snyder javali...@cbfiddle.com wrote:
 
 I will do that, but a larger question remains:
 
 Are any of the AWT classes currently reported by jdeps as “JDK internal API” 
 going to be accessible in JDK 9?
 

No - there is no known RFE that I know of may provide a replacement for 
sun.awt.* classes except  /JDK-8067470 (see [1] for client related internal 
APIs). The best is to bring up the discussion to awt-dev as Alan suggests.

https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool 
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool 
tracks what internal APIs that have known replacement or will have supported 
APIs in a future release.   This is a living document that will be updated if 
there is any new RFE to provide a replacement to existing internal APIs.



 I ask because of this comment by Stuart Marks:
 
 Unfortunately, com.sun is a mixture of internal and publicly supported 
 (exported) APIs. An annotation @jdk.Exported distinguishes the latter from 
 internal APIs.
 
 Who decides which APIs get this annotation? Are these annotations in place 
 now?

@jdk.Exported was added in JDK 8.  

I suggest you look at the exported APIs listed under:
   http://hg.openjdk.java.net/jdk9/dev/file/tip/modules.xml

This is an interim solution to declare what APIs are exported until the module 
system moves further along and defines a proper module definition.

Mandy

[1] https://bugs.openjdk.java.net/browse/JDK-8065418

Re: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management

[Mandy Chung]

On 3/31/2015 9:39 AM, shanliang wrote:

Please review this fix:

Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/


Thank you for doing this big change to separate com.sun.management
API from java.management module.   Looking really good.

Also thanks for fixing the tests to eliminate the unnecessary use of
JDK internal APIs.

modules.xml change looks good to me.

sun/management/ThreadImpl.java
  35 /**
  36  * Implementation class for the thread subsystem.
  37  * Standard and committed hotspot-specific metrics if any.
  38  *
  39  * ManagementFactory.getThreadMXBean() returns an instance
  40  * of this class.
  41  */
  42 // the implementation for com.sun.management.ThreadMXBean can
  43 // be moved to jdk.management in the future.

What about:
  Implementation for java.lang.management.ThreadMXBean as well as
  providing the supporting method for com.sun.management.ThreadMXBean.
  
  The supporting method for com.sun.management.ThreadMXBean can

  be moved to jdk.management in the future.

CheckSomeMXBeanImplPackage.java
   Thanks for adding this test.

   Iterating jrt file system to find jdk.management module is one way.
   Another simpler alternative is to call:
 Class.forName(com.sun.management.GarbageCollectorMXBean);
   and catch CNFE to determine if it's present or not.

   You should also call ManagementFactory.getPlatformMXBeans on
   com.sun.management.GarbageCollectorMXBean if present.

VMOptionOpenDataTest.java
   copyright header year is wrong.

PlatformMBeanProviderConstructorCheck.java
   The test needs to restore the original policy and security manager
   before the test exits in case this case runs in agent vm mode.
   The static permName and accepted variables are more appropriate
   in MyPolicy class.  Perhaps rename accepted to an instance
   denied or allowed variable of MyPolicy class to reflect
   what it intends to mean.

I'm okay if you make the change before the push.  No need for a new
webrev.

Mandy

Re: RFR: JDK-8080511 - Refresh of jimage support

[Mandy Chung]

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
modules.xml looks fine.

test/lib/sun/hotspot/WhiteBox.java
This adds the native entry points.  Where are they implemented?  It’s 
not obvious to me.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
the jdeps change looks fine.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk/
This is a huge patch that I have to rely on the extensive testing to catch 
potential issues.  I tried running the jrt-fs tests using JDK 8 with jrt-fs.jar 
that work well.   Some comments and mostly minor.

make/gensrc/Gensrc-jdk.dev.gmk
 - you could revert this one

make/src/classes/build/tools/module/ImageBuilder.java
 Nit: line 366, 382 - left over commented lines
 some indentation/formatting nits line 386-397

jdk/tools/jimage/TaskHelper.java
43 static final long serialVersionUID = 8765093759964640721L;  // ## 
re-generate

jdk/tools/jimage/JImageTask.java
The start year is replaced in the copyright header.   You should add the end 
year instead.

test/java/nio/Buffer/LimitDirectMemory.sh
test/java/nio/file/spi/SetDefaultProvider.java
   Why this test is ignored? 

Mandy

 On Jun 17, 2015, at 5:08 PM, Jim Laskey (Oracle) james.las...@oracle.com 
 wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
 This includes native support for reading jimage files, improved jrt-fs (java 
 runtime file system) support for retrieving modules and packages from the 
 runtime, and improved performance for langtools in the presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing in 
 hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.
 

Re: RFR: JDK-8080511 - Refresh of jimage support

[Mandy Chung]

 On Jun 19, 2015, at 6:27 AM, Alan Bateman alan.bate...@oracle.com wrote:
 
 
 
 On 18/06/2015 19:48, Mandy Chung wrote:
 :
 
 test/java/nio/Buffer/LimitDirectMemory.sh
 test/java/nio/file/spi/SetDefaultProvider.java
Why this test is ignored?
 
 
 For LimitDirectMemory.sh then the test needs to be adjusted to take account 
 of the direct buffers that the jimage code is created. We can do this after 
 Jim's push if it makes things easier.
 
 The SetDefaultProvider.java test is more tricky. I suggested to Jim that he 
 exclude it temporarily because interposing on the default provider with this 
 version of jimage code will lead to recursive initialization issues. Once we 
 get to one jimage file and replacing the ext/app class loaders then it will 
 become a non-issue and we liberate the test then.

It’s fine to exclude them.   Jean-Francois - can you file a bug and add the bug 
number next to @ignore?

Mandy

Re: Review Request 8074432: Move jdeps to jdk.compiler module

[Mandy Chung]

It’s in my repo but missing from the webrev.

diff --git a/make/launcher/Launcher-jdk.jdeps.gmk 
b/make/launcher/Launcher-jdk.jdeps.gmk
new file mode 100644
--- /dev/null
+++ b/make/launcher/Launcher-jdk.jdeps.gmk
@@ -0,0 +1,36 @@
+#
+# Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
+# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+#
+# This code is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License version 2 only, as
+# published by the Free Software Foundation.  Oracle designates this
+# particular file as subject to the Classpath exception as provided
+# by Oracle in the LICENSE file that accompanied this code.
+#
+# This code is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# version 2 for more details (a copy is included in the LICENSE file that
+# accompanied this code).
+#
+# You should have received a copy of the GNU General Public License version
+# 2 along with this work; if not, write to the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+# or visit www.oracle.com if you need additional information or have any
+# questions.
+#
+
+include LauncherCommon.gmk
+
+$(eval $(call SetupLauncher,javap, \
+-DEXPAND_CLASSPATH_WILDCARDS \
+-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \
+-DJAVA_ARGS='{ -J-ms8m$(COMMA) com.sun.tools.javap.Main$(COMMA) }'))
+
+$(eval $(call SetupLauncher,jdeps, \
+-DEXPAND_CLASSPATH_WILDCARDS \
+-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \
+-DJAVA_ARGS='{ -J-ms8m$(COMMA) com.sun.tools.jdeps.Main$(COMMA) }'))

 On May 27, 2015, at 12:48 AM, Erik Joelsson erik.joels...@oracle.com wrote:
 
 Hello Mandy,
 
 I don't see a Launcher-jdk.jdeps.gmk. Should there be one?
 
 /Erik
 
 On 2015-05-27 08:00, Mandy Chung wrote:
 We discussed this offline and revised the proposal to group javap and 
 classfile library together with jdeps in jdk.jdeps module for static 
 analysis tools to live.  The jdk.compiler module will contain the compiler 
 and a couple of small tools.  Moving out javap and classfile library save 
 about 1.2M uncompressed from jdk.compiler (~11%).
 
 The module is named after the primary tool, jdeps in this case.  Tools are 
 in JAVA_HOME/bin directory of idk image and so which module jdeps and javap 
 are transparent in the idk image.
 
 Revised webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/
 
 This touches many langtools tests to update @modules but should be easy to 
 review.
 
 $ du -s -h jdk.jdeps/com/sun/tools/*
 816K jdk.jdeps/com/sun/tools/classfile
 468K jdk.jdeps/com/sun/tools/javap
 400K jdk.jdeps/com/sun/tools/jdeps
 $ du -s -h jdk.compiler/
 9.1M jdk.compiler/
 
 Mandy
 

Re: Review Request 8074432: Move jdeps to jdk.compiler module

[Mandy Chung]

We discussed this offline and revised the proposal to group javap and classfile 
library together with jdeps in jdk.jdeps module for static analysis tools to 
live.  The jdk.compiler module will contain the compiler and a couple of small 
tools.  Moving out javap and classfile library save about 1.2M uncompressed 
from jdk.compiler (~11%).

The module is named after the primary tool, jdeps in this case.  Tools are in 
JAVA_HOME/bin directory of idk image and so which module jdeps and javap are 
transparent in the idk image. 

Revised webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/

This touches many langtools tests to update @modules but should be easy to 
review.

$ du -s -h jdk.jdeps/com/sun/tools/*   
816Kjdk.jdeps/com/sun/tools/classfile
468Kjdk.jdeps/com/sun/tools/javap
400Kjdk.jdeps/com/sun/tools/jdeps
$ du -s -h jdk.compiler/ 
9.1Mjdk.compiler/

Mandy

Re: Jigsaw Hackday in London - Anything in particular you want us to look at?

[Mandy Chung]

FYI.  The RFE concerning sun.misc.SignalHandler is:
https://bugs.openjdk.java.net/browse/JDK-8087286

Mandy

 On Jun 29, 2015, at 5:43 AM, Richard Warburton richard.warbur...@gmail.com 
 wrote:
 
 Hi,
 
 This is a good point actually. I have also used that class before as it
 seems to be the only way to hook those signals in a commandline app.
 
 I appreciate its a difficult case to deal with since you cant safely run
 Java code inside a signal handler callback because signal handler callback
 code must be reentrant safe but it feels like having some kind of Java
 level hook for this kind of signal would be useful. Even if it is
 asynchronous.
 
 regards,
 
  Richard
 On 29 Jun 2015 12:15, Tglman tgl...@tglman.com wrote:
 
 Hi All,
 
 I am a library developer, and in some cases in the project i work on is
 used Unsafe, and we already planning to replace it with other solutions.
 anyway while i was trying to test my project on jdk9 i found that also
 other api we use are removed.
 In my spefic case we use also 'sun.misc.SignalHandler', is this api
 going to be available in future following the same approach used for
 sun.misc.Unsafe ?
 
 Is it there any replacement for handling not shutdown/kill/interrupt
 signals ?
 (In my specific case we catch also SIGTRAP)
 
 Thank You
 
 Emanuele
 
 
 
 
 On 23/06/15 17:12, mark.reinh...@oracle.com wrote:
 2015/6/23 8:45 -0700, vita...@gmail.com:
 Yes, but until all the safe replacements are in place and vetted (e.g.
 performance is on par with Unsafe, same functionality is available,
 etc), I
 don't see the point of making it even more annoying to grab hold of.
 The
 people who are using it will continue using it until the replacements
 are
 available, and this is just going to annoy them.
 That's precisely the point.
 
 sun.misc.Unsafe and its ilk will go away one day.  In preparation for
 that, making it a bit harder to use will motivate its current users to
 consider whether they really do need to use it -- some do, but some
 don't.
 
 If you absolutely do need it then now is the time to start looking at
 the alternatives in development, and contribute to those efforts in
 order to make sure that your needs are met.  Paul's work on variable
 handles (JEP 193 [1]), e.g., is far enough along that feedback would
 be useful.
 
 Making sun.misc.Unsafe harder to use will also help the many users who
 unknowingly depend upon this unsupported API, via libraries which do
 depend upon it, to become aware of that dependence.  They can then
 either seek alternatives or ask the maintainers of those libraries to
 do so.
 
 - Mark
 
 
 [1] http://openjdk.java.net/jeps/193
 
 

Re: Review Request 8074432: Move jdeps to jdk.compiler module

[Mandy Chung]

Meant to include jigsaw-dev in the initial post.

 On May 25, 2015, at 12:16 AM, Alan Bateman alan.bate...@oracle.com wrote:
 
 On 24/05/2015 05:00, Mandy Chung wrote:
 This will move jdeps to the same module as other langtools javac and javap.
 
 Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.00/
 
 This is the final change to resolve the open issue JDK-8072601 (Re-examine 
 jdk.runtime and jdk.dev modules) for JEP 200.
 
 Mandy
 I don't see any issues with the patch but I wonder if this is a case where we 
 should introduce jdk.jdeps rather than putting the tool in the jdk.compile 
 module.
 


serialver and javap are in jdk.compiler that is an appropriate home for jdeps 
while I don’t particularly like it since it isn’t clear to tell from 
jdk.compiler module name where jdeps is there.

The tool modules have been evolved a bit and some tools are put in its own 
module such as jdk.pack200, jdk.policytool, jdk.javadoc, jdk.jconsole, jdk.rmic 
etc.  that are organized around its primary tool which is easy to name, 
document, and understand.

Putting jdeps in jdk.jdeps module makes it easy where to find jdeps that is an 
attractive option. 

This also opens up the option to move jdeps to jdk repo in the future - it is 
just a side point and jdeps is currently being used as an interim solution to 
verify module boundaries until the module system is moving further along.

I will post a revised webrev.

 A passing comment is that I see we run these tools with -Xms8m, we should 
 re-visit that some day.
 

Yes - we should re-visit this for the launchers we have.

Mandy

Re: Review for JDK-8132527

[Mandy Chung]

On 08/18/2015 01:34 AM, Jean-Francois Denise wrote:

Hi,
asking for review to fix jvm crashing when replacing jimage file with recreated 
one.

The name of the module metadata resource was wrongly associated to the name of 
the recreated jimage file. The original name must be reused in the recreated 
jimage.
This is what this fix is doing. In addition the jimage unit test has been 
extended to cover the case where the provided jimage path is relative.

http://cr.openjdk.java.net/~jfdenise/8132527/


This looks okay. For JimageTest.java  test, after it recreates the 
image, can you add to launch java -version from the recreated image as 
a sanity test?


Mandy

hg: jigsaw/jake/langtools: Add jdeps -R -ct option.

[mandy . chung]

Changeset: f99c96f9f9f9
Author:mchung
Date:  2015-10-21 22:29 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f99c96f9f9f9

Add jdeps -R -ct option.
Also remove -verify:access option.

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties

hg: jigsaw/jake/jdk: 8138626: java.awt.Window.applyResourceBundle fails to find resource bundle

[mandy . chung]

Changeset: 22839e63cbda
Author:okutsu
Date:  2015-10-25 19:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/22839e63cbda

8138626: java.awt.Window.applyResourceBundle fails to find resource bundle
Reviewed-by: mchung

! src/java.desktop/share/classes/java/awt/Window.java

Re: RFR: 8140336: Add @modules for exported dependencies to jdk_core tests

[Mandy Chung]

> On Oct 26, 2015, at 10:13 AM, Alexandre (Shura) Iline 
>  wrote:
> 
> Hi.
> 
> Could you please take a look on the suggested change in tests belonging to 
> jdk_core test group.
> 
> Pls notice that the dependencies which would later be removed by fixing 
> JDK-8139430 we not added in this change.
> 
> http://cr.openjdk.java.net/~shurailine/8140336/webrev.01/

Thanks for the patch.

This change is against jake/jdk repo.  I assume you intend to integrate this 
change to jdk9/dev/jdk.  You can separate into two changesets, one for 
jdk9/dev/jdk and the other for test/jdk/jigsaw tests that I can push your 
change to test/jdk/jigsaw tests to jake.

test/java/lang/ProcessHandle/TEST.properties
- which test references types in jdk.management?   If there is only a couple of 
tests depending on jdk.management, better to use @modules in those individual 
tests instead.

Is java.management module pulled in due to the test library in the following 
tests?
test/java/lang/instrument/RedefineBigClass.sh
test/java/lang/instrument/RedefineMethodInBacktrace.sh
test/java/lang/instrument/RetransformBigClass.sh
test/java/lang/instrument/NativeMethodPrefixAgent.java

It’s okay to remove java.management dependency later by JDK-8139430.   At the 
same time, would it be easier not to update the tests that require 
java.management due to the test library and let JDK-8139430 fixes it?
 
Mandy

hg: jigsaw/jake/jdk: Jlink plugin for fast reconstitution of module descriptors of installed modules

[mandy . chung]

Changeset: 06bc945b812d
Author:mchung
Date:  2015-10-26 17:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06bc945b812d

Jlink plugin for fast reconstitution of module descriptors of installed modules
To enable this plugin, use jlink --gen-installed-modules on option.

- src/java.base/share/classes/java/lang/module/Checks.java
! src/java.base/share/classes/java/lang/module/InstalledModuleFinder.java
! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/module/ModulePath.java
! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java
! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java
+ src/java.base/share/classes/jdk/internal/module/Builder.java
+ src/java.base/share/classes/jdk/internal/module/Checks.java
+ src/java.base/share/classes/jdk/internal/module/InstalledModules.java
+ 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java
+ 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorProvider.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPools.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
! src/jdk.jlink/share/classes/module-info.java
! test/jdk/jigsaw/tools/jlink/JLinkTest.java

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

[Mandy Chung]

Resource file of zero-length module name and package name should not be allowed 
to be written to jimage.  The moduleName > 0 and packageName > 0 should be an 
assertion; exception if fails.

Mandy

> On Oct 29, 2015, at 1:09 PM, Dmitry Samersoff  
> wrote:
> 
> Roger,
> 
> ImageNativeSubstrate.cpp:565
> 
>two extra bytes is accounted if moduleLen == 0
> 
> Please, add examples of valid resource name when moduleLen == 0 and/or
> packageLen == 0 to comments.
> 
> 
> -Dmitry
> 
> On 2015-10-28 09:40, Roger Riggs wrote:
>> Please review an update to the jimage reader implementation to correct the
>> case where a class name is very long causing a SEGV due to buffer overruns.
>> 
>> The fix will be pushed to the hs-comp repo; the bug was first spotted
>> there.
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390
>> 
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8139390
>> 
>> Thanks, Roger
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

[Mandy Chung]

> On Oct 27, 2015, at 11:40 PM, Roger Riggs  wrote:
> 
> Please review an update to the jimage reader implementation to correct the
> case where a class name is very long causing a SEGV due to buffer overruns.
> 
> The fix will be pushed to the hs-comp repo; the bug was first spotted there.

I suggest to push it to jdk9/dev and that will be pulled into hs-comp when it’s 
sync’ed up. 

> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390

Looks okay in general.  

ImageNativeSubstrate.cpp
Is this native JIMAGE_FindResource method intended for tests to use?  I 
don’t find any reference to it besides tests.  The other option is to have a 
java method checking null parameters and call this native method (and make this 
native method private).

test/jdk/internal/jimage/JImageReadTest.java
169 Assert.assertTrue(max > 16000,
170 "missing entries, should be more than 31000, reported: " + 
count);

Is the change from 31000 to 16000 accidental?

This is unrelated to your change and just to mention it.  The test hardcodes 
9.0 as the version and the hardcoded value should be replaced for future 
release.   Probably best to file a JBS issue for that.

Mandy

Re: RFR 9: 8139390 : Very long classname in jimage causes SIGSEGV

[Mandy Chung]

> On Oct 29, 2015, at 4:22 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
> 
> Hi Mandy,
> 
> Collapsing the emails.
> 
> As for asserting that module name is never null;
> it appears that the module name is not being supplied by the VM. (in hs-comp 
> or jdk9).
> 
> On 10/29/15 12:59 PM, Mandy Chung wrote:
>>> On Oct 27, 2015, at 11:40 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
>>> 
>>> Please review an update to the jimage reader implementation to correct the
>>> case where a class name is very long causing a SEGV due to buffer overruns.
>>> 
>>> The fix will be pushed to the hs-comp repo; the bug was first spotted there.
>> I suggest to push it to jdk9/dev and that will be pulled into hs-comp when 
>> it’s sync’ed up.
> ok, the issue was with HS tests failing and pushing to hs-comp more rapidly 
> addresses that.
> But I'm fine with pushing to jdk9.
> 
> (BTW, there is a different fix for this issue expected to be reimplemented 
> for Jake).
>> 
>>> Webrev:
>>>   http://cr.openjdk.java.net/~rriggs//webrev-jimage-segv-8139390
>> Looks okay in general.
>> 
>> ImageNativeSubstrate.cpp
>> Is this native JIMAGE_FindResource method intended for tests to use?  I 
>> don’t find any reference to it besides tests.  The other option is to have a 
>> java method checking null parameters and call this native method (and make 
>> this native method private).
> yes, it is only being used to specifically test the native JIMAGE_xxx native 
> functions.

Since the fix will be reimplemented in jake, it would be better to hide this 
native method and do the null check in java.  This would require existing tests 
to change.

It’s okay with your version as an interim fix.

>> 
>> test/jdk/internal/jimage/JImageReadTest.java
>> 169 Assert.assertTrue(max > 16000,
>> 170 "missing entries, should be more than 31000, reported: " 
>> + count);
>> 
>> Is the change from 31000 to 16000 accidental?
> When I added a test for a long classname, I discovered that the test was not 
> properly marked with @test
> and was not being run.  When I re-enabled it, I observed that the number of 
> entries
> was quite a bit smaller than previously and so updated the test.

I see.  line 170 should be updated for the new number.
>> 
>> This is unrelated to your change and just to mention it.  The test hardcodes 
>> 9.0 as the version and the hardcoded value should be replaced for future 
>> release.   Probably best to file a JBS issue for that.
> I thought I had seen a change to allow a default version to be used.  But at 
> the moment the
> argument is ignored and until it is not ignored this value is immaterial.

I filed https://bugs.openjdk.java.net/browse/JDK-8140803 to track this.

Mandy

hg: jigsaw/jake/jdk: Jake patch for 8140336: Add @modules for exported dependencies to jdk_core tests

[mandy . chung]

Changeset: 1b632228f7e5
Author:shurailine
Date:  2015-10-27 20:12 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b632228f7e5

Jake patch for 8140336: Add @modules for exported dependencies to jdk_core tests
Reviewed-by: alanb, mchung

! test/java/lang/Class/GetModuleTest.java
! test/java/lang/Package/annotation/PackageInfoTest.java
! test/jdk/jigsaw/etc/resources/ResourcesTest.java
! test/jdk/jigsaw/invoke/access/ModuleAccessControlTest.java
! test/jdk/jigsaw/launcher/addexports/AddExportsTest.java
! test/jdk/jigsaw/launcher/addmods/AddModsTest.java
! test/jdk/jigsaw/launcher/addreads/AddReadsTest.java
! test/jdk/jigsaw/launcher/basic/BasicTest.java
! test/jdk/jigsaw/launcher/limitmods/LimitModsTest.java
! test/jdk/jigsaw/launcher/patch/PatchTest.java
! test/jdk/jigsaw/launcher/upgrademodulepath/UpgradeModulePathTest.java
! test/jdk/jigsaw/module/ModuleReader/ModuleReaderTest.java
! test/jdk/jigsaw/reflect/Module/BasicModuleTest.java
! test/jdk/jigsaw/reflect/Module/access/AccessTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyTest.java
! test/jdk/jigsaw/scenarios/automaticmodules/RunWithAutomaticModules.java
! test/jdk/jigsaw/scenarios/container/ContainerTest.java
! test/jdk/jigsaw/scenarios/overlappingpackages/OverlappingPackagesTest.java
! test/jdk/jigsaw/tools/jimage/JImageTest.java
! test/jdk/jigsaw/tools/jlink/CustomImageBuilderTest.java
! test/jdk/jigsaw/tools/jlink/CustomPluginTest.java
! test/jdk/jigsaw/tools/jlink/DefaultProviderTest.java
! test/jdk/jigsaw/tools/jlink/IntegrationTest.java
! test/jdk/jigsaw/tools/jlink/JLink2Test.java
! test/jdk/jigsaw/tools/jlink/JLinkNegativeTest.java
! test/jdk/jigsaw/tools/jlink/JLinkOptimTest.java
! test/jdk/jigsaw/tools/jlink/JLinkOptionsTest.java
! test/jdk/jigsaw/tools/jlink/JLinkPluginsTest.java
! test/jdk/jigsaw/tools/jlink/JLinkPostProcessingTest.java
! test/jdk/jigsaw/tools/jlink/JLinkTest.java
! test/jdk/jigsaw/tools/jlink/NativeTest.java
! test/jdk/jigsaw/tools/jlink/basic/BasicTest.java
! test/jdk/jigsaw/tools/jlink/hashes/HashesTest.java
! test/jdk/jigsaw/tools/jlink/plugins/PluginOrderTest.java
! test/jdk/jigsaw/tools/jlink/plugins/StringSharingPluginTest.java
! test/jdk/jigsaw/tools/jlink/plugins/StripDebugPluginTest.java
! test/jdk/jigsaw/tools/jmod/JmodNegativeTest.java
! test/jdk/jigsaw/tools/jmod/JmodTest.java
! test/jdk/jigsaw/util/ServiceLoader/ServicesTest.java

Re: RFR: 8140336: Add @modules for exported dependencies to jdk_core tests

[Mandy Chung]

> On Oct 27, 2015, at 6:36 AM, Alexandre (Shura) Iline 
>  wrote:
> 
> I have created two separate reviews:
> http://cr.openjdk.java.net/~shurailine/8140336/webrev.jdk9.02/
> http://cr.openjdk.java.net/~shurailine/8140336/webrev.jake.02/

Thanks.

I have pushed webrev.jdk9.02 to jdk9/dev and webrev.jake.03 to jake.

> 
>> 
>> test/java/lang/ProcessHandle/TEST.properties
>> - which test references types in jdk.management?   If there is only a couple 
>> of tests depending on jdk.management, better to use @modules in those 
>> individual tests instead.
> 
> The dependency is coming through java/lang/ProcessHandle/JavaChild.java. 
> Three of five tests in the dir use it: InfoTest.java, OnExitTest.java, 
> TreeTest.java.
> 
> Yes, I could update just the three tests, but since JTReg will compile all 
> the classes in the dir, the compilation for the rest of the tests will fail 
> if no jdk.management present. Instead I would rather have the fix as it is 
> right now and have a separate bug to fix this later. Which is what I was 
> going to do.
> 

That’s okay.  Just need to make sure the java.management dependency is removed 
when  JDK-8139430 is resolved.

Mandy

Re: Technical question about the Java Dependency Analysis Tool

[Mandy Chung]

jdeps already has the option finding the JAR files needed to compile A.jar.

There is a new jdeps option added to Jigsaw EA build [1] to make this easier:

$ jdeps -s -ct -R -cp lib/* A.jar

This will transitively find all dependencies from the references in A.jar and 
shows the summary of the JAR-level dependencies.  jdeps -dotoutput option 
outputs the dependencies in a DOT file that you can generate the DOT graph.

You can use idk 9  jdeps —include option which analyzes all JAR files in lib 
directory
$ jdeps —dotoutput dotfiles —include “.*” -cp lib/* A.jar

Mandy
[1] http://openjdk.java.net/projects/jigsaw/ea

> On Nov 9, 2015, at 9:26 PM, Richard Callahan  wrote:
> 
> Hi,
> 
> I have a specific question about the output from the Java Dependency Analysis 
> Tool (JDeps), released with Open JDK 8. Thank you very much for such a 
> marvelous tool!
> 
> I am parsing the output from JDeps with the "-v" flag set, such that a call 
> to JDeps produces all class-level dependencies among and within a set of JAR 
> files in a directory specified by the user. Consider a directed graph G 
> constructed from the JDeps output, with the vertices representing nodes in 
> the graph and the edges representing dependencies among the classes as 
> specified in the JDeps output.  My question is, if a specific JAR file in the 
> directory (call it A.jar) can compile using OpenJDK with the other JAR files 
> in the directory designated as dependencies, then does there always exist at 
> least one subgraph G' of G that corresponds to the dependency relationships 
> that would be actually used by a Java compiler to compile A.jar? If the 
> answer is "yes," then I believe I should be able to recover that graph by 
> starting with the set of classes in A.jar and then constructing the subgraph 
> G' in a manner similar to that used by a depth-first search.
> 
> Thank you for your time, I recognize it is valuable.
> 
> Best,
> 
> Richard

Re: RFR: 8139430

[Mandy Chung]

> On Nov 10, 2015, at 10:11 AM, Alexandre (Shura) Iline 
> <alexandre.il...@oracle.com> wrote:
> 
>> 
>> On Nov 10, 2015, at 9:04 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
>> 
>> Hi Shura,
>> 
>> Thanks for doing it and it’s good to see the unnecessary dependency to 
>> java.management eliminated.
>> 
>> The new jdk.testlibrary.management package name is fine.  It’s okay to keep 
>> the class name InputArguments as Jaroslav suggests and it’s easier to tell 
>> what this class is about.
>> 
>> There is a copy of ProcessTools and InputArguments in the hotspot repository 
>> under
>>  hotspot/test/testlibrary/jdk/test/lib/
>> 
>> Are we planning to remove this duplicated copy?  If not, same patch should 
>> be applied to those copy. It’s fine to separate this and push the hotspot 
>> test library change via hotspot-rt repo.  Christian can probably sponsor the 
>> patch for you.
> 
> This is the bug to track the library merge:
> https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> It is there for a long time for discussion, so I would not suggest to wait 
> for it. If a parallel fix is needed, I would rather just do it. 
> 

I agree.  I suggest to file a bug and apply this fix in the hotspot test 
library as a separate patch.

Mandy

Re: RFR: 8139430

[Mandy Chung]

Hi Shura,

Thanks for doing it and it’s good to see the unnecessary dependency to 
java.management eliminated.

The new jdk.testlibrary.management package name is fine.  It’s okay to keep the 
class name InputArguments as Jaroslav suggests and it’s easier to tell what 
this class is about.

There is a copy of ProcessTools and InputArguments in the hotspot repository 
under
   hotspot/test/testlibrary/jdk/test/lib/

Are we planning to remove this duplicated copy?  If not, same patch should be 
applied to those copy.  It’s fine to separate this and push the hotspot test 
library change via hotspot-rt repo.  Christian can probably sponsor the patch 
for you.

I’ll sponsor the jdk change and push it to jdk9/dev once you send me an updated 
patch.

Mandy


> On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline 
>  wrote:
> 
> Hi
> 
> I have just realized that an NPE could also be possible in 
> test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated 
> also:
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
> 
> Shura
> 
>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline 
>>  wrote:
>> 
>> Hi,
>> 
>> This is one of the ways to fix 8139430: 
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
>> 
>> Could you please take a look on it?
>> 
>> A few comments. 
>> 
>> The biggest dependency on java.management was in 
>> jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the 
>> method to use the new process API, which helped to avoid updating a lot of 
>> code.
>> 
>> I am moving the rest library code which depended on java.management and 
>> jdk.management  to a new “management" subpackage of the jdk library: 
>> jdk.testlibrary.management. Another possibility I have considered is “ext” 
>> or “extended” subpackage, which would have all the classes which depend on 
>> anything but java.base. With “ext” there would be no way to keep the desired 
>> granularity with the test modules dependencies.
>> 
>> The methods which worth moving fit well into two classes: 
>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method 
>> which previously belonged to the TestThread utility methods.
>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as 
>> jdk.testlibrary.InputArguments
>> 
>> None of moved/renamed test library methods were used anywhere in tests, so 
>> no test updates needed:
>> jdk.testlibrary.InputArguments is not used, instead every test which needs 
>> that functionality directly calls RuntimeMXBean.getInputArguments()
>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, 
>> Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were 
>> not used as there is a similar class outside of the test library:
>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java
>> 
>> Please let me know what you think.
>> 
>> Shura
> 

Re: Proposal to enhance jdeps tool to search split packages/add some kind of general API

[Mandy Chung]

> On Nov 12, 2015, at 2:39 AM, Patrick Reinhart  wrote:
> 
> Hi there,
> 
> I like to do some early adoption tests with software using the new module 
> system. Now we got an unknown amount of split packages in our system, the we 
> will need to fix in order to migrate our codebase.
> 
> I could imagine, that there are other potential users of the JDK, that have 
> the same problem to solve. So I think it would be a good thing to have some 
> detection within the jdeps tool or even have some kind of an API that could 
> be used otherwise (as of in a IDE).
> 
> Now I wanted to know what you think about this? I would also be prepared to 
> do some work in that area.

A tool to detect split packages and some other characteristics to aid migration 
to modules would be useful.   I tend to think that belongs to a different tool 
that can build other additional analysis in it.

For split packages, it’d be useful to differentiate if the split package 
contains overlapping classes vs partitioned classes.   For partitioned classes, 
renaming the package would likely be one solution if it doesn’t need to live in 
a specific namespace.  For overlapping classes, one possibility is that the 
class path contains multiple copies of the same version or different version or 
patched version of a library, or redistribution.

Mandy

hg: jigsaw/jake/jdk: Backout compressed resource header length change that breaks windows build

[mandy . chung]

Changeset: 103e023995ba
Author:mchung
Date:  2015-11-12 18:51 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/103e023995ba

Backout compressed resource header length change that breaks windows build

! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java
! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp
! src/java.base/share/native/libjimage/imageDecompressor.cpp
! src/java.base/share/native/libjimage/imageDecompressor.hpp
! src/java.base/share/native/libjimage/imageFile.cpp

hg: jigsaw/jake/jdk: 161 new changesets

[mandy . chung]

Changeset: 0198481aa9bd
Author:lana
Date:  2015-10-19 00:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0198481aa9bd

Added tag jdk9-b87 for changeset 110fc90bdfa0

! .hgtags

Changeset: e860e54043fd
Author:aefimov
Date:  2015-10-10 12:52 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e860e54043fd

8139107: DateTimeFormatter with Locale.UK throw a NullPointerException when 
parsing zone
Reviewed-by: naoto

! 
src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java
! src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java
+ test/sun/util/resources/TimeZone/Bug8139107.java

Changeset: 3bd60f298de4
Author:chegar
Date:  2015-10-10 17:27 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bd60f298de4

8139307: Remove sun.misc.ConditionLock and Lock
Reviewed-by: alanb, lancea, martin, mchung, shade, smarks

- src/java.base/share/classes/sun/misc/ConditionLock.java
- src/java.base/share/classes/sun/misc/Lock.java

Changeset: 7fea29aaa921
Author:chegar
Date:  2015-10-10 17:30 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7fea29aaa921

8139179: URLStreamHandler* should link to URL ctor that specifies how 
factories/providers are located
Reviewed-by: alanb

! src/java.base/share/classes/java/net/URLStreamHandlerFactory.java
! src/java.base/share/classes/java/net/spi/URLStreamHandlerProvider.java

Changeset: de8723d4d615
Author:amlu
Date:  2015-10-12 17:07 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de8723d4d615

8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing
Reviewed-by: chegar

! test/java/rmi/registry/readTest/readTest.sh

Changeset: d1aa33d3720c
Author:dfuchs
Date:  2015-10-12 20:13 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1aa33d3720c

8033661: readConfiguration does not cleanly reinitialize the logging system
Summary: two new updateConfiguration methods have been added to LogManager: 
call updateConfiguration to update a configuration *after* the LogManager is 
initialized.
Reviewed-by: mchung

! src/java.logging/share/classes/java/util/logging/LogManager.java
+ 
test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java
+ 
test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java
+ 
test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigWithInputStreamTest.java
+ 
test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigurationTest.java
+ 
test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java

Changeset: 640d543aea86
Author:chegar
Date:  2015-10-12 19:14 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/640d543aea86

8139297: java.lang.NoClassDefFoundError: Could not initialize class 
jdk.internal.jimage.ImageNativeSubstrate
Reviewed-by: alanb, jlaskey

! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java

Changeset: fed8b8b53b4b
Author:plevart
Date:  2015-10-14 00:08 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fed8b8b53b4b

8136893: Improve early java.lang.invoke infrastructure initialization
Reviewed-by: mhaupt, psandoz, redestad, vlivanov

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MemberName.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java

Changeset: 96524d5330db
Author:dl
Date:  2015-10-13 16:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96524d5330db

8134851: Integrate CompletableFuture with API enhancements
8039378: CompletableFuture: Avoid StackOverflowError for long linear chains
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/CompletionStage.java
! test/java/util/concurrent/CompletableFuture/Basic.java
! test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java
! test/java/util/concurrent/CompletableFuture/ThenComposeExceptionTest.java

Changeset: a0c71499805e
Author:dl
Date:  2015-10-13 16:15 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0c71499805e

8134852: Integrate fork/join with API enhancements
Reviewed-by: martin, psandoz, chegar

! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java
! 

hg: jigsaw/jake/nashorn: 43 new changesets

[mandy . chung]

Changeset: 061682b25ca9
Author:lana
Date:  2015-10-19 00:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/061682b25ca9

Added tag jdk9-b87 for changeset 0bf2fe0c7b32

! .hgtags

Changeset: 0cae16c0043d
Author:attila
Date:  2015-10-12 10:27 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0cae16c0043d

8139273: Small improvements to DynamicLinker and DynamicLinkerFactory
Reviewed-by: lagergren, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java

Changeset: 494bc9750691
Author:attila
Date:  2015-10-12 10:28 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/494bc9750691

8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn
Reviewed-by: lagergren, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java

Changeset: 6c6df82265f0
Author:mhaupt
Date:  2015-10-12 13:36 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6c6df82265f0

8139266: add JSAdapter example with fallthrough
Reviewed-by: attila, hannesw

+ samples/jsadapter-fallthrough.js

Changeset: 0a640d17732d
Author:attila
Date:  2015-10-12 13:44 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0a640d17732d

8139270: Drastically reduce memory footprint of ChainedCallSite
Reviewed-by: hannesw, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java

Changeset: 022f7146248d
Author:attila
Date:  2015-10-12 14:52 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/022f7146248d

8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits
Reviewed-by: mhaupt, sundar

! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NoSuchDynamicMethodException.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AccessibleMembersLookup.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/GuardedInvocationComponent.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java
! 

hg: jigsaw/jake: 65 new changesets

[mandy . chung]

Changeset: 0c140bff9257
Author:lana
Date:  2015-10-19 00:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0c140bff9257

Added tag jdk9-b87 for changeset fd4f4f756107

! .hgtags

Changeset: a7ec2278c13d
Author:ihse
Date:  2015-10-12 11:49 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a7ec2278c13d

8139413: Use --with-x to set X11 root directory
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/lib-x11.m4

Changeset: 81b90ca627de
Author:lana
Date:  2015-10-15 16:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/81b90ca627de

Merge


Changeset: 0bb87e05d83e
Author:lana
Date:  2015-10-21 15:15 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0bb87e05d83e

Merge


Changeset: 9c467f2d46f0
Author:lana
Date:  2015-10-22 08:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9c467f2d46f0

Added tag jdk9-b88 for changeset 0bb87e05d83e

! .hgtags

Changeset: c867c33f584b
Author:jlahoda
Date:  2015-10-19 19:13 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c867c33f584b

8134254: JShell API/tool: REPL for Java into JDK9
Summary: Adding jdk.jshell module into modules.xml; and listing it among 
TOOLS_MODULES.
Reviewed-by: alanb, erikj, sundar
Contributed-by: robert.fi...@oracle.com, jan.lah...@oracle.com

! make/Images.gmk
! modules.xml

Changeset: a60a0c1bd394
Author:erikj
Date:  2015-10-20 09:47 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a60a0c1bd394

8139735: Switch compilers in JPRT for windows and linux
Reviewed-by: tbell, ihse

! make/devkit/Tools.gmk
! make/devkit/createWindowsDevkit.sh
! make/jprt.properties

Changeset: 24a3936909e3
Author:ihse
Date:  2015-10-20 10:39 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/24a3936909e3

8139668: Generate README-build.html from markdown
Reviewed-by: erikj

! README-builds.html
+ README-builds.md
+ common/bin/update-build-readme.sh

Changeset: 257534f191e8
Author:ihse
Date:  2015-10-20 16:40 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/257534f191e8

8139969: Fix unzip in compare.sh broken by JDK-8136813
Reviewed-by: erikj

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: cb3f10185e63
Author:erikj
Date:  2015-10-20 17:29 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/cb3f10185e63

8139813: Base heap size on type of boot jdk, not architecture of build machine
Reviewed-by: tbell, ihse

! common/autoconf/boot-jdk.m4
! common/autoconf/generated-configure.sh

Changeset: 8851df90bb66
Author:erikj
Date:  2015-10-02 17:33 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/8851df90bb66

8138739: Enable devkit on macosx in JPRT (again)
Reviewed-by: ihse

! make/jprt.properties

Changeset: 11c070dc7985
Author:ddehaven
Date:  2015-10-06 12:51 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/11c070dc7985

Merge


Changeset: efbea01d5b5c
Author:prr
Date:  2015-10-12 14:44 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/efbea01d5b5c

Merge

- common/autoconf/builddeps.conf.example
- common/autoconf/builddeps.conf.nfs.example
- common/autoconf/builddeps.m4

Changeset: a44eac54cdc3
Author:prr
Date:  2015-10-20 08:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a44eac54cdc3

Merge

! make/jprt.properties

Changeset: 827ea558b8a3
Author:prr
Date:  2015-10-20 10:33 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/827ea558b8a3

Merge


Changeset: 998803eeed50
Author:neliasso
Date:  2015-09-18 10:09 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/998803eeed50

8135068: Extract method matchers from CompilerOracle
Summary: Ecapsulate code to enable reuse
Reviewed-by: roland, kvn

! test/lib/sun/hotspot/WhiteBox.java

Changeset: b9acee978e94
Author:iveresov
Date:  2015-09-25 12:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b9acee978e94

Merge


Changeset: fd80ddb7553f
Author:amurillo
Date:  2015-10-01 11:52 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/fd80ddb7553f

Merge


Changeset: 0b5d2c8bd667
Author:amurillo
Date:  2015-10-08 14:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0b5d2c8bd667

Merge


Changeset: 483de5dbcd96
Author:dsamersoff
Date:  2015-09-24 20:39 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/483de5dbcd96

8086134: Deadlock detection fails to attach to core file
Summary: Test reimplemented for jtreg
Reviewed-by: jbachorik

! test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java
+ test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java

Changeset: 34280222936a
Author:jwilhelm
Date:  2015-09-28 15:05 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/34280222936a

Merge


Changeset: 9261bce638e3
Author:jwilhelm
Date:  2015-10-07 00:46 +0200
URL:   

hg: jigsaw/jake/jdk: Add new modular resource bundle test

[mandy . chung]

Changeset: f83388bef364
Author:okutsu
Date:  2015-11-13 22:20 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f83388bef364

Add new modular resource bundle test

+ 
test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithNoModuleArg.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithUnnamedModuleArg.java
+ test/java/util/ResourceBundle/modules/visibility/src/embargo/module-info.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResources.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/props/MyResources.properties
+ 
test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResources.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResources.properties
+ 
test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/named.bundles/module-info.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/classes/MyResources.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/props/MyResources.properties
+ 
test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/test/Main.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithNoModuleArg.java
+ 
test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithUnnamedModuleArg.java
+ test/java/util/ResourceBundle/modules/visibility/src/test/module-info.java
+ test/java/util/ResourceBundle/modules/visibility/visibility.sh

Re: JDeps: detecting offending packages

[Mandy Chung]

> On Nov 14, 2015, at 7:20 AM, Alan Bateman  wrote:
> 
> On 13/11/2015 21:58, Robert Scholte wrote:
>> :
>> 
>> Previous versions of JDK9 gave me the following output:
>> 
>> classes -> java.base
>>(classes)
>>  -> java.io
>>  -> java.lang
>>  -> sun.misc   JDK internal API 
>> (java.base)
>> 
>> 
>> The current b86 gives me:
>> 
>> classes -> java.base
>>(classes)
>>  -> java.io
>>  -> java.lang
>>  -> sun.misc
>> 
>> So why this change? And is there another way to detect the usage of 
>> non-accessible classes?
>> 
>> The maven-plugin has a parameter called failOnWarning (default:true) which 
>> should break the build in order to help developers to change their code when 
>> they rely on internal classes.
> 
> In the regular JDK 9 EA builds then a usage of sun.misc.BASE64Decoder will be 
> reported as a usage of a JDK internal API.
> 
> Not so with the Jigsaw builds because package sun.misc is temporarily 
> exported by module java.base. This means that all public types in that 
> package are accessible. This might seem surprising but it is because we're 
> not there yet with JEP 260 [1]. Once JEP 260 is further along thne the 
> critical internal APIs listed in JEP 260 will be accessible. The non-critical 
> internal APIs will be encapsulated.

I think jdeps should continue to flag the critical JDK internal APIs listed in 
JEP 260 but they are accessible at runtime.  I file a bug:

https://bugs.openjdk.java.net/browse/JDK-8143011

> 
> For the Maven plugin then maybe it might be better to choose a JDK-internal 
> type that is not in sun.misc or sun.reflect. That would keep your test stable 
> while we work through all the transition issues.


Yes that allows to work through the transition.

Mandy

hg: jigsaw/jake/langtools: 39 new changesets

[mandy . chung]

Changeset: 288f18dd9157
Author:lana
Date:  2015-10-19 00:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/288f18dd9157

Added tag jdk9-b87 for changeset 45f796d8cdcd

! .hgtags

Changeset: 79e637c1e083
Author:mcimadamore
Date:  2015-10-12 12:24 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/79e637c1e083

8138840: NPE when compiling bitwise operations with illegal operand types
8139243: compiler crashes with exception on sum operation of String var and 
void method call result
8139249: Compiler crashes on unary bitwise complement with non-integral operand
Summary: Certain binary operator checks are accepting more operands than 
required.
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Operators.java
+ test/tools/javac/8138840/T8138840.java
+ test/tools/javac/8138840/T8138840.out
+ test/tools/javac/8138840/T8139243.java
+ test/tools/javac/8138840/T8139243.out
+ test/tools/javac/8138840/T8139249.java
+ test/tools/javac/8138840/T8139249.out

Changeset: 700677b16a97
Author:sadayapalam
Date:  2015-10-12 19:43 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/700677b16a97

8139245: compiler crashes with exception on int:new method reference and 
generic method inference
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.java
+ test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.out

Changeset: 814a0cab8c90
Author:sadayapalam
Date:  2015-10-13 09:48 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/814a0cab8c90

8000316: Huge performance bottleneck in 
com.sun.tools.javac.comp.Check.localClassName
Summary: Speed up Check.localClassName by avoiding generating names known to be 
in use already
Reviewed-by: mcimadamore, jlahoda, sadayapalam
Contributed-by: dmitry.chu...@oracle.com

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/T8000316/T8000316.java

Changeset: 575ea88f69a5
Author:chegar
Date:  2015-10-13 09:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/575ea88f69a5

8139371: Three langtools test failures after the removal of sun.misc.Lock
Reviewed-by: jjg, mchung

! test/tools/javac/proprietary/WarnClass.java
! test/tools/javac/proprietary/WarnClass.out
! test/tools/javac/warnings/6594914/T6594914b.java
! test/tools/javac/warnings/6594914/T6594914b.out
! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/m/Gee.java

Changeset: 126e5c6abd1d
Author:lana
Date:  2015-10-15 16:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/126e5c6abd1d

Merge


Changeset: ac57d80b205d
Author:lana
Date:  2015-10-21 15:15 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ac57d80b205d

Merge


Changeset: 4789df418bc3
Author:lana
Date:  2015-10-22 08:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4789df418bc3

Added tag jdk9-b88 for changeset ac57d80b205d

! .hgtags

Changeset: 23f76aadbb36
Author:ksrini
Date:  2015-09-11 16:34 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/23f76aadbb36

8078320: Improve DocTrees parsing.
Reviewed-by: jjg, jlahoda

! src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/doclint/HtmlTag.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/tools/javac/doctree/DocCommentTester.java
! test/tools/javac/doctree/ElementTest.java
! test/tools/javac/doctree/FirstSentenceTest.java
+ test/tools/javac/doctree/InPreTest.java
! test/tools/javac/doctree/TagTest.java

Changeset: 777c5a760a84
Author:jlahoda
Date:  2015-10-19 12:41 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/777c5a760a84

8139751: Javac crash with -XDallowStringFolding=false
Summary: When string folding is disabled, need to keep the original expression.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/tools/javac/parser/StringFoldingTest.java

Changeset: 15bdc18525ff
Author:jlahoda
Date:  2015-10-19 19:15 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/15bdc18525ff

8134254: JShell API/tool: REPL for 

hg: jigsaw/jake/hotspot: 226 new changesets

[mandy . chung]

Changeset: bc48b669bc66
Author:lana
Date:  2015-10-19 00:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc48b669bc66

Added tag jdk9-b87 for changeset d7ffd16382fe

! .hgtags

Changeset: b0e0a53226fd
Author:lana
Date:  2015-10-22 08:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0e0a53226fd

Added tag jdk9-b88 for changeset bc48b669bc66

! .hgtags

Changeset: e1517978bf12
Author:enevill
Date:  2015-09-15 12:59 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1517978bf12

8136524: aarch64: test/compiler/runtime/7196199/Test7196199.java fails
Summary: Fix safepoint handlers to save 128 bits on vector poll
Reviewed-by: kvn
Contributed-by: felix.y...@linaro.org

! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

Changeset: 43451068d53c
Author:roland
Date:  2015-09-15 13:08 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43451068d53c

8136461: PhaseIdealLoop::try_move_store_before_loop() may bypass early loop exit
Summary: PhaseIdealLoop::try_move_store_before_loop() needs to check for early 
loop exit before candidate Stores
Reviewed-by: kvn

! src/share/vm/opto/loopopts.cpp
- test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java
+ test/compiler/loopopts/TestMoveStoresOutOfLoopsStoreNoCtrl.java

Changeset: cc267038a9c1
Author:kvn
Date:  2015-09-15 11:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc267038a9c1

8136406: Remove ZapDeadCompiledLocals code
Summary: Dead code elimination.
Reviewed-by: roland, twisti

! agent/src/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapSet.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/compiler/oopMap.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 65c21ccab1bd
Author:kvn
Date:  2015-09-16 20:33 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/65c21ccab1bd

Merge


Changeset: 10e79692c25e
Author:mcberg
Date:  2015-09-16 13:16 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/10e79692c25e

8134802: LCM register pressure scheduling
Summary: Calculate register pressure in a block to help instructions scheduling.
Reviewed-by: kvn, dlong

! src/cpu/aarch64/vm/aarch64.ad
! src/cpu/aarch64/vm/c2_globals_aarch64.hpp
! src/cpu/ppc/vm/c2_globals_ppc.hpp
! src/cpu/ppc/vm/ppc.ad
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/node.hpp

Changeset: a60e232aa8f2
Author:kvn
Date:  2015-09-16 15:54 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a60e232aa8f2

8134553: CRC32C implementations for x86/x64 targets
Reviewed-by: kvn
Contributed-by: tomasz.wojtow...@intel.com

! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp
! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
+ src/cpu/x86/vm/crc32c.h
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86.cpp
! src/cpu/x86/vm/stubRoutines_x86.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/zero/vm/interpreterGenerator_zero.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/runtime/stubRoutines.cpp
! 

hg: jigsaw/jake/jaxp: 18 new changesets

[mandy . chung]

Changeset: 4700fd67e942
Author:lana
Date:  2015-10-19 00:25 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4700fd67e942

Added tag jdk9-b87 for changeset eb435c878c2c

! .hgtags

Changeset: 27b625ce80f4
Author:lana
Date:  2015-10-22 08:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/27b625ce80f4

Added tag jdk9-b88 for changeset 4700fd67e942

! .hgtags

Changeset: 00fa5efc9ace
Author:joehw
Date:  2015-04-18 00:17 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/00fa5efc9ace

8068842: Better JAXP data handling
Reviewed-by: dfuchs, lancea, hawtin

! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltSets.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
- 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java
! 

hg: jigsaw/jake/jdk: 3 new changesets

[mandy . chung]

Changeset: 5babde7bd078
Author:jjg
Date:  2015-11-13 15:55 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5babde7bd078

8142996: move jdk java/util/streams tests into java.base directories
Reviewed-by: mchung

! test/java/util/stream/bootlib/TEST.properties
+ test/java/util/stream/bootlib/java.base/java/util/stream/CollectorOps.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/DefaultMethodStreams.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestDataProvider.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/FlagDeclaringOp.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestDataProvider.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestScenario.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/IntermediateTestOp.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/LambdaTestHelpers.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LambdaTestMode.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/LoggingTestCase.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestDataProvider.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/OpTestCase.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StatefulTestOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/StatelessTestOp.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/StreamOpFlagTestHelper.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestDataProvider.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestScenario.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/TestData.java
+ 
test/java/util/stream/bootlib/java.base/java/util/stream/TestFlagExpectedOp.java
+ test/java/util/stream/bootlib/java.base/java/util/stream/ThowableHelper.java
- test/java/util/stream/bootlib/java/util/stream/CollectorOps.java
- test/java/util/stream/bootlib/java/util/stream/DefaultMethodStreams.java
- 
test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java
- test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java
- test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
- test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
- test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java
- test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
- test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
- test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java
- test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java
- test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java
- test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java
- test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java
- test/java/util/stream/bootlib/java/util/stream/TestData.java
- test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java
- test/java/util/stream/bootlib/java/util/stream/ThowableHelper.java
! test/java/util/stream/boottest/TEST.properties
+ test/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/FlagOpTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/IntNodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/LongNodeTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/NodeBuilderTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/NodeTest.java
+ 
test/java/util/stream/boottest/java.base/java/util/stream/SliceSpliteratorTest.java
+ 
test/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/StreamFlagsTest.java
+ 
test/java/util/stream/boottest/java.base/java/util/stream/StreamOpFlagsTest.java
+ test/java/util/stream/boottest/java.base/java/util/stream/StreamReuseTest.java
- test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
- test/java/util/stream/boottest/java/util/stream/FlagOpTest.java
- 

hg: jigsaw/jake/hotspot: Add uses/provides for jdk.vm.ci module

[mandy . chung]

Changeset: 40952d9e4128
Author:mchung
Date:  2015-11-16 22:11 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/40952d9e4128

Add uses/provides for jdk.vm.ci module

! src/jdk.vm.ci/share/classes/module-info.java

Re: RFR: 8139430

[Mandy Chung]

> On Nov 16, 2015, at 5:38 AM, Alan Bateman  wrote:
> 
> 
> 
> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote:
>> V6:
>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/
>> 
>> 
> This looks okay to me. For completeness then I assume the 
> THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status 
> if interrupted when waiting.

+1

Mandy

Re: RFR: 8139430

[Mandy Chung]

> On Nov 10, 2015, at 12:42 PM, Alan Bateman  wrote:
> 
> Would it break many tests if getProcessId were changed to return long to 
> match ProcessHandle::getPid?

There are not small number of tests doing 
   Integer.toString(ProcessTools.getProcessId()));

Most of them are in hotspot and there are about 10 in jdk repo.   Perhaps the 
tests should simply be changed to call:
   ProcessHandle.current().getPid();

> 
> When this is pushed then can we drop @modules java.management from any tests 
> or were those changes held back assuming the dependency would be dropped?

I think Shura prefers to do this patch on ProcessTools and update the 
dependency in another bulk update.   It’d be good if this can be done together.

Mandy

hg: jigsaw/jake/jdk: 8139067: Re-examine if a consumer module should load bundles from unnamed module

[mandy . chung]

Changeset: 1ac78e4a10d5
Author:okutsu
Date:  2015-10-29 19:55 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ac78e4a10d5

8139067: Re-examine if a consumer module should load bundles from unnamed module
Reviewed-by: alanb, mchung, naoto

! 
src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java
! test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh
! test/java/util/ResourceBundle/modules/basic/basic.sh
! test/java/util/ResourceBundle/modules/modlocal/modlocal.sh
! test/java/util/ResourceBundle/modules/simple/simple.sh

hg: jigsaw/jake/jdk: Enable jlink gen-installed-modules plugin by default

[mandy . chung]

Changeset: 3f859f4a29bf
Author:mchung
Date:  2015-11-07 13:02 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f859f4a29bf

Enable jlink gen-installed-modules plugin by default

! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java
! 
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorProvider.java

Re: JOSM feedback on Java 7,8,9, including Jigsaw EA

[Mandy Chung]

Thanks for reporting these issues.

> On Oct 30, 2015, at 8:29 AM, Vincent Privat  
> wrote:
> 
> Concerning Jigsaw:
> - We have reported 3 bugs. All made it to the public JIRA: 8138878,
> 8140477, 8140481. The second one is a bit problematic for our tests as it
> basically kills our Jenkins instance. I see the two other ones are
> understood/in progress. We will do more tests after we resolve the hanging
> problem.

8140481 is a build issue that should be fixed shortly.

8138878 breaks through resource encapsulation.  jake b86 fixes InternalError 
and throws MissingResourceException if it attempts to get a bundle in 
java.desktop named module.

We’ll look into these bugs.

> 
> - We'd like to know if it can be expected to see the
> package sun.security.x509 become a public JDK API, for example in
> javax.security.cert? We currently use it to generate a self-signed
> certificate in order to create a local https server. That's our only use of
> private JDK API.

There are two RFEs related to signing and certificates
  8058778: New APIs for some keytool functions
  8056174: New APIs for jar signing

I have added this comment in 8058778 for the security team to look into.  You 
can subscribe to security-...@openjdk.java.net  where the discussion for these 
RFEs will be.

Mandy

Re: RFR: 8139067: Re-examine if a consumer module should load bundles from unnamed module

[Mandy Chung]

> On Oct 29, 2015, at 4:55 PM, Masayoshi Okutsu  
> wrote:
> 
> Hello,
> 
> Please review the change for JDK-8139067. A consumer module 
> (ResourceBundle.getBundle caller) will no longer load resource bundles from 
> the class-path if the consumer module is a named module. Test programs, basic 
> and modlocal, have been changed to confirm .properties bundles are not loaded 
> from a jar file on the class-path.The webrev also include some cleanup of 
> @bug and @summary for the test programs.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8139067
> 
> Webrev: http://cr.openjdk.java.net/~okutsu/9/8139067/webrev.00

The ResourceBundleProviderSupport change looks good to me.  It is reasonable to 
expect that the consumer of the resource bundles and the bundle modules should 
migrate to named module at the same time.  Resource bundles are generally 
application-specific. 

Mandy

hg: jigsaw/jake/langtools: Should not generate module-info.java if it contains an unnamed package

[mandy . chung]

Changeset: ce2237f87c34
Author:mchung
Date:  2015-10-20 23:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ce2237f87c34

Should not generate module-info.java if it contains an unnamed package

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java

hg: jigsaw/jake/langtools: Initial support for jdeps -genmoduleinfo option

[mandy . chung]

Changeset: 9504efc77849
Author:mchung
Date:  2015-10-20 23:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9504efc77849

Initial support for jdeps -genmoduleinfo option

! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Mandy Chung]

On 10/08/2015 05:41 AM, Alan Bateman wrote:

I'm not sure
that I agree with logging a warning when
java.beans.ConstructorProperties is used. I would be tempted to leave
that out.


The idea is that we want users to stop using @j.b.CP for JMX 
purposes. So we might as well warn them about the suboptimal solution 
they are using. But I don't insist on the logging.
Ideally the warning would be at compile-time but it's not going to 
work here. I would be tempted to just drop this, others might have 
different opinions.


I also think the warning is not necessary.   It'd be interesting to find 
out how many MXBean and how many of them are annotated with j.b.@CP from 
Maven Central.  I suspect not too many.   Definitely we should document 
the recommendation in the release note and other documents like tutorial 
and guides.


Mandy

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Mandy Chung]

On 10/08/2015 04:49 AM, Jaroslav Bachorik wrote:

Please, review the following change

Issue : https://bugs.openjdk.java.net/browse/JDK-7199353
Webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.00/top
http://cr.openjdk.java.net/~jbachorik/7199353/webrev.00/jdk



I think #2 in the rules listed in "Reconstructing an instance of Java 
type J from a CompositeData" section needs some clarification/rewording.


#2 says if J has at least one public constructor with j.m.@CP
- in fact J has at least one public constructor with either j.m.@CP or 
j.b.@CP


I think it's more appropriate to mention j.m.@CP takes precedence in #2 
instead of adding the "For backward compatibility" paragraph.


What about removing the new "For backward compatibility paragraph," 
and update #2 as something like this:


2. Otherwise, if /J/ has at least one public constructor with either 
j.m.CP or j.b.CP annotation, then one of those constructors be 
called to reconstruct an instance of /J/. If a constructor is annotated 
with both j.m.CP or j.b.CP, j.m.CP will be used and j.b.CP will be 
ignored.  


The existing tests are modified to use 
j.m.annotation.ConstructorProperties.  Can you remove java.desktop from 
@modules list if the test no longer depends on java.desktop.


The new package.html file: should use package-info.java instead.

Mandy

Re: jlink plugin experiment to improve jake startup time

[Mandy Chung]

I realize I missed the attachment after seeing Claes’ question.  This includes 
the heap usage after GC.






> On Oct 5, 2015, at 2:13 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
> I have been experimenting a jlink plugin to improve the module system startup 
> time.   On a Quad-Core Intel Xeon E5 @3.7 GHz, 16G memory (Mac Pro) machine, 
> the module system startup takes 110 ms and 75% of it is to reconstitute 64 
> module descriptors with 2388 packages altogether.
> 
> This high overhead includes initializing lambda forms (class loading, 
> linking, initialization), parsing of module-info.class and compilation of 
> many methods during startup.
> 
> The attached charts shows the summary of module system startup
> 1) jake-b83 (as of Sep 29)
>module bootstrap time  110 ms
>module descriptor reconstitution 82 ms
>VM startup time is 3x of jdk9-b83 vm startup time (148ms vs 47 ms)
> 
> 2) No lambda at startup
>module bootstrap time66 ms  (saved 44 ms compared to #1)
>module descriptor reconstitution 33.6 ms (saved 48.4ms)
>VM startup time is 2.2x of jdk9-b83 (105ms vs 47ms)
> 
> 
> 3) jlink plugin to generate a .class file to build module descriptors at link 
> time
>module bootstrap time50.7 ms  (saved 15.3ms compared to #2)
>module descriptor reconstitution 16.8 ms (saved 16.8ms)
>VM startup time is 1.9x of jdk9-b83 (90ms vs 47ms)
> 
> For #3, it parses module-info.class at link time and validates all names.  It 
> generates a .class file to call a custom Builder to create ModuleDescriptor 
> for the installed modules.  At runtime, the generated class will construct 
> the Builder and ModuleDescriptor objects will skip name validation, no 
> defensive copy of the input set/map and skip reading and parsing of 
> module-info.class (this is done by a special module descriptor builder class 
> that doesn’t use lambda.  This special builder is only used by installed 
> modules).
> 
> It saves 15.3 ms (23% of the module system bootstrap time in #2).   The 
> downside of this optimization is a little harder to make change and diagnose 
> (this plugin implementation is straight forward though).   There may be other 
> small optimization to explore that could be done at jlink time (e.g. 
> BuiltinClassLoader maintains a package to module map that can be constructed 
> with a specific size to avoid map resizing).
> 
> What’s your thought/opinion to integrate this jlink plugin into jake?
> 
> Mandy
> 

hg: jigsaw/jake/jdk: Fix InternalError thrown by Class.forName

[mandy . chung]

Changeset: f7e100339605
Author:mchung
Date:  2015-10-12 20:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f7e100339605

Fix InternalError thrown by Class.forName

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

hg: jigsaw/jake/jdk: 2 new changesets

[mandy . chung]

Changeset: e5fcea3aa679
Author:mchung
Date:  2015-11-17 15:12 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5fcea3aa679

Enable the test case to verify unnamed module fails to load properties bundle 
from named module

! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java

Changeset: 5aadb299a052
Author:mchung
Date:  2015-11-17 15:13 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5aadb299a052

Merge

Re: jdeps and annotations parameters

[Mandy Chung]

Just to double check: are you using 8u60 jdeps?  or jdk9 jdeps?

Mandy

On 09/01/2015 11:59 AM, Jeff Hain wrote:


Back from trying to figure out all the cases where
jdeps and my utility don't compute the same dependencies,
for classes of JDK8_60/rt.jar, and each time which
is right.


What I did is modify my code to make it behave like
jdeps for each encountered difference, and then
re-run the comparison to see what was left.


Below I list all the cases for usage of jdeps
with "-verbose:class -filter:none" options,
i.e. when computing all dependencies, API or not
(with "-apionly" option there were many more
differences, possibly due to assumptions about
what "API" means - we could exclude that for now).



1) Jdeps ignores dependencies caused by package-info
class files.
===> Maybe intended?

Ex.:
@javax.xml.bind.annotation.XmlSchema(namespace = 
"http://xmlns.oracle.com/webservices/jaxws-databinding;, 
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)

package com.oracle.xmlns.internal.webservices.jaxws_databinding;
===> Doesn't see dependencies to
java.lang.Object
and
javax.xml.bind.annotation.XmlSchema



2) Jdeps ignores types of parameters of annotations
(as said in initial mail).

Ex. (in java.beans):
@Documented @Target(CONSTRUCTOR) @Retention(RUNTIME)
public @interface ConstructorProperties {
String[] value();
}
===> Doesn't see dependencies to
java.lang.annotation.ElementType
and
java.lang.annotation.RetentionPolicy.

===> Could reproduce the behavior by ignoring/skipping
"element_value" items.



3) Jdeps doesn't parse class signatures containing generic types
properly, but it does fine for fields or methods signatures.

Ex. (in java.lang.management.PlatformComponent):
interface MXBeanFetcher {
public List getMXBeans();
}
===> Doesn't see dependency to
java.lang.management.PlatformManagedObject.

===> For example, dependency to Object is properly computed from signature
 "Ljava/lang/ThreadLocal;"
 but not from
"Ljava/lang/ThreadLocal<TE;>;".

===> Could reproduce the behavior by skipping all characters following ':'
 up to the '>' closing the scope.



4) Jdeps doesn't compute a dependency to java.lang.Deprecated when
@deprecated or @Deprecated is only in the Javadoc,
in which case there is no "Ljava/lang/Deprecated;" descriptor/signature
in the class file but still a "Deprecated" attribute.
===> Maybe intended?

Ex.: javax.xml.bind.Validator

===> Could reproduce the behavior by skipping "Deprecated" attributes,
and only having dependency to java.lang.Deprecated due to the 
descriptor/signature.




5) Jdeps ignores (some? all?) dependencies to
com.sun.istack.internal.NotNull
and
com.sun.istack.internal.Nullable

Ex. (in com.sun.istack.internal.Pool):
public interface Pool {
@NotNull T take();
void recycle(@NotNull T t);
}
===> Doesn't see dependencies to
com.sun.istack.internal.NotNull

===> Could not find a way to reproduce this behavior, other than
having specific cases for these annotations.
I created a similar test class, with a similar annotation @MyNotNull,
and jdeps would detect it (???).



6) For java.util.stream.FindOps, jdeps properly doesn't compute
a dependency to java.util.stream.TerminalSink (which is only
used in nested classes), but for some reason there is a
"()Ljava/util/stream/TerminalSink;" descriptor in FindOps.class
(???) so my library considers there is the dependency...



Lastly a few remarks about -apionly:

jdeps help says it restricts the analysis to dependences
"from the signature of public and protected members of public
classes including field type, method parameter types,
returned type, checked exception types etc"

But:

1) It can actually compute dependencies from a protected,
   package-private or private class, for example if they
   have public fields.
   Maybe it should not be the case for (package-)private
   classes (or whenever there is a non-API class in the
   way to the top level class), because it would show
   transitive dependencies that could not be followed
   through the API.
   (Ex.:
private class Priv {public Double getDouble(){...}}
public class Pub {public Priv getPriv(){...}}
===> Through the API we could never go from Pub to Double
 but according to jdeps it would be possible.)

2) It does not consider public and protected nested classes
   as dependencies (even though they are in the API
   of the class).

3) Should annotations of APIs be considered APIs?
   (at least for some trivial cases they are)



-Jeff


*De :* Jeff Hain <jeffh...@rocketmail.com>
*À :* Mandy Chung <mandy.ch...@oracle.com>; 
"jigsaw-dev@openjdk.java.net" <jigsaw-dev@openjdk.java.net>

*Envoyé le :* Jeudi 27 août 2015 23h24
*Objet :* Re: jdep

Re: jdeps and annotations parameters

[Mandy Chung]

Hi Jeff,

Thanks for the feedback that is helpful.

jdeps is static analysis tool reporting class dependencies to help 
existing code for modularization.  So jdeps should report the list of 
class names matching the list that are needed during compilation as 
closely as possible.   It looks at Signature, RuntimeVisibleAnnotations 
and RuntimeVisibleParameterAnnotations attributes but not other 
attributes in the current implementation that explains some of the 
questions you pointed.


My comments are inlined below from my initial evaluation.  I am 
including your report in JDK-8134625 to be addressed together.


On 09/01/2015 11:59 AM, Jeff Hain wrote:


Back from trying to figure out all the cases where
jdeps and my utility don't compute the same dependencies,
for classes of JDK8_60/rt.jar, and each time which
is right.


What I did is modify my code to make it behave like
jdeps for each encountered difference, and then
re-run the comparison to see what was left.


Below I list all the cases for usage of jdeps
with "-verbose:class -filter:none" options,
i.e. when computing all dependencies, API or not
(with "-apionly" option there were many more
differences, possibly due to assumptions about
what "API" means - we could exclude that for now).



1) Jdeps ignores dependencies caused by package-info
class files.
===> Maybe intended?

Ex.:
@javax.xml.bind.annotation.XmlSchema(namespace = 
"http://xmlns.oracle.com/webservices/jaxws-databinding;, 
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)

package com.oracle.xmlns.internal.webservices.jaxws_databinding;
===> Doesn't see dependencies to
java.lang.Object
and
javax.xml.bind.annotation.XmlSchema



javax.xml.bind.annotation.XmlSchema is needed to compile 
package-info.java and so I think it should be reported.



2) Jdeps ignores types of parameters of annotations
(as said in initial mail).

Ex. (in java.beans):
@Documented @Target(CONSTRUCTOR) @Retention(RUNTIME)
public @interface ConstructorProperties {
String[] value();
}
===> Doesn't see dependencies to
java.lang.annotation.ElementType
and
java.lang.annotation.RetentionPolicy.

===> Could reproduce the behavior by ignoring/skipping
"element_value" items.



Enum and Class element value should be reported.




3) Jdeps doesn't parse class signatures containing generic types
properly, but it does fine for fields or methods signatures.

Ex. (in java.lang.management.PlatformComponent):
interface MXBeanFetcher {
public List getMXBeans();
}
===> Doesn't see dependency to
java.lang.management.PlatformManagedObject.

===> For example, dependency to Object is properly computed from signature
 "Ljava/lang/ThreadLocal;"
 but not from
"Ljava/lang/ThreadLocal;".

===> Could reproduce the behavior by skipping all characters following ':'
 up to the '>' closing the scope.



I would think it should report it.  I will have to look at this one.



4) Jdeps doesn't compute a dependency to java.lang.Deprecated when
@deprecated or @Deprecated is only in the Javadoc,
in which case there is no "Ljava/lang/Deprecated;" descriptor/signature
in the class file but still a "Deprecated" attribute.
===> Maybe intended?

Ex.: javax.xml.bind.Validator

===> Could reproduce the behavior by skipping "Deprecated" attributes,
and only having dependency to java.lang.Deprecated due to the 
descriptor/signature.




I think we should skip Deprecated attribute since this is for 
documentation although a source may need java.lang.Deprecated type to 
compile (@Deprecated on a method e.g.)




5) Jdeps ignores (some? all?) dependencies to
com.sun.istack.internal.NotNull
and
com.sun.istack.internal.Nullable

Ex. (in com.sun.istack.internal.Pool):
public interface Pool {
@NotNull T take();
void recycle(@NotNull T t);
}
===> Doesn't see dependencies to
com.sun.istack.internal.NotNull

===> Could not find a way to reproduce this behavior, other than
having specific cases for these annotations.
I created a similar test class, with a similar annotation @MyNotNull,
and jdeps would detect it (???).




I think it should but I'll check this out in details.


6) For java.util.stream.FindOps, jdeps properly doesn't compute
a dependency to java.util.stream.TerminalSink (which is only
used in nested classes), but for some reason there is a
"()Ljava/util/stream/TerminalSink;" descriptor in FindOps.class
(???) so my library considers there is the dependency...



Lastly a few remarks about -apionly:

jdeps help says it restricts the analysis to dependences
"from the signature of public and protected members of public
classes including field type, method parameter types,
returned type, checked exception types etc"



-apionly is useful to separate dependencies due to implementation vs API.


But:

1) It can actually compute dependencies from a protected,
   package-private or private class, for example if they
   have public fields.
   Maybe it should not be the case for (package-)private
   classes (or 

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Mandy Chung]

On 09/10/2015 01:55 PM, Jim Connors wrote:


When you run the com.greetings.Main class via:

$ java -mp mods -m com.greetings/com.greetings.Main

The Quick Start guide shows the output as:

class org.fastsocket.FastNetworkSocket

The Main.java file referenced above prints nothing (at least in my 
case), would it have to be modified slightly, something like:


$ cat src/com.greetings/com/greetings/Main.java
package com.greetings;

import com.socket.NetworkSocket;

public class Main {
public static void main(String[] args) {
NetworkSocket s = NetworkSocket.open();
System.out.println(s.getClass().toString());
   }
}



I think you are right.  The System.out.println is missing in the sample 
code in the quickstart guide.  The key point there is to show that the 
service provider implementation class is loaded.


Mandy

Mandy

hg: jigsaw/jake/langtools: 2 new changesets

[mandy . chung]

Changeset: 144597c5a68b
Author:jlahoda
Date:  2015-09-12 10:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/144597c5a68b

Fixing langtools tests broken by recent merge.

! test/ProblemList.jake.txt
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/lambda/TestBootstrapMethodsCount.java
! test/tools/javac/lib/combo/ReusableContext.java

Changeset: ceff7728eb4c
Author:mchung
Date:  2015-09-12 10:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ceff7728eb4c

Fixup @modules in combo tests

! test/ProblemList.jake.txt
! test/tools/javac/resolve/BitWiseOperators.java

Re: CFV: New Jigsaw Committer: Harold Seigel

[Mandy Chung]

Vote: yes

Mandy

hg: jigsaw/jake/jaxp: 2 new changesets

[mandy . chung]

Changeset: 53fe3c103b6f
Author:lana
Date:  2015-09-11 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/53fe3c103b6f

Added tag jdk9-b81 for changeset 6a418934997f

! .hgtags

Changeset: faade39222ae
Author:mchung
Date:  2015-09-11 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/faade39222ae

Merge

Re: CFV: New Jigsaw Committer: Lois Foltan

[Mandy Chung]

Vote: yes

Re: CFV: New Committer: Christian Tornqvist

[Mandy Chung]

Vote: yes

hg: jigsaw/jake/jdk: Exception typo in Proxy class javadoc

[mandy . chung]

Changeset: 3f905b5efebf
Author:mchung
Date:  2015-09-17 15:14 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f905b5efebf

Exception typo in Proxy class javadoc

! src/java.base/share/classes/java/lang/reflect/Proxy.java

hg: jigsaw/jake/hotspot: fixing XoverrideCCDS.java test failure

[mandy . chung]

Changeset: e6b7e9cc28c0
Author:ccheung
Date:  2015-09-17 14:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e6b7e9cc28c0

fixing XoverrideCCDS.java test failure
Summary: adjusted the expected error message during dump time
Reviewed-by: iklam, jiangli

! test/runtime/modules/XoverrideCDS.java

hg: jigsaw/jake/jdk: Class::getPackage should return null for array type, primitive type or void

[mandy . chung]

Changeset: 375469dd1809
Author:mchung
Date:  2015-10-02 08:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/375469dd1809

Class::getPackage should return null for array type, primitive type or void

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
+ test/java/lang/Class/Foo.java
+ test/java/lang/Class/GetPackageTest.java

hg: jigsaw/jake/jdk: jdk.hprof.agent has been removed and module loader map needs update

[mandy . chung]

Changeset: 937f4cfe2cab
Author:mchung
Date:  2015-10-02 16:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/937f4cfe2cab

jdk.hprof.agent has been removed and module loader map needs update

! make/gensrc/GensrcModuleLoaderMap.gmk

Re: Re-examine ClassLoader.getPackage(s) methods

[Mandy Chung]

> On Sep 26, 2015, at 7:33 AM, Alan Bateman  wrote:
> This looks good. I think I would lean more to deprecating getPackage as just 
> too fragile and leads to difficult to diagnose bugs.

Are you also suggesting to deprecate ClassLoader::getPackages as well?
 
> BTW: I assume the proxy test is a separate change-set and not mean to be in 
> this patch.

That test should be pushed as a separate changeset.  That test reveals a NPE 
thrown by definePackage and helps catching problem.

Mandy

hg: jigsaw/jake/jaxws: Update jaxws to look up resources from named modules

[mandy . chung]

Changeset: 49c4220a2a43
Author:mkos
Date:  2015-09-29 11:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/49c4220a2a43

Update jaxws to look up resources from named modules

! 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/server/SDDocumentSource.java
! 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointImpl.java
! 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java

hg: jigsaw/jake/jdk: 2 new changesets

[mandy . chung]

Changeset: 5f781c90d35b
Author:mchung
Date:  2015-09-28 16:31 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f781c90d35b

New test to create proxies with layer

+ test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java

Changeset: 189f83e533d0
Author:mchung
Date:  2015-09-28 16:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/189f83e533d0

8137096: Typo in j.l.r.Proxy.newProxyInstance - 'and and'

! src/java.base/share/classes/java/lang/reflect/Proxy.java

hg: jigsaw/jake/jdk: Deprecate Package::getPackage as ClassLoader::getPackage does

[mandy . chung]

Changeset: deb77851e5fd
Author:mchung
Date:  2015-09-29 12:36 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/deb77851e5fd

Deprecate Package::getPackage as ClassLoader::getPackage does

! src/java.base/share/classes/java/lang/Package.java
! src/java.desktop/share/classes/java/awt/Component.java

Re: Re-examine ClassLoader.getPackage(s) methods

[Mandy Chung]

On 09/27/2015 01:29 AM, Alan Bateman wrote:



On 26/09/2015 19:28, Mandy Chung wrote:
On Sep 26, 2015, at 7:33 AM, Alan Bateman <alan.bate...@oracle.com> 
wrote:
This looks good. I think I would lean more to deprecating getPackage 
as just too fragile and leads to difficult to diagnose bugs.

Are you also suggesting to deprecate ClassLoader::getPackages as well?
The ordering of the elements in the array returned by CL::getPackages 
is not specified so I think that is okay. However 
CL#getPackage(String) is a significant hazard as the @apiNote explains 
so I think it could be a candidate to deprecate.


Thanks for clarifying this as I think no need to deprecate CL::getPackags.

Custom class loader implementation may likely call CL::getPackage before 
calling definePackage to avoid IAE.  There isn't any issue filed 
reporting the returned Package contains unexpected properties.   On the 
other hand, now each class loader defines Package objects locally 
without walking the class loader hierarchy, I agree that deprecating 
CL::getPackage is the right thing.


I now make @apiNote in CL::getPackage to @deprecated.

 * @deprecated
 * If multiple class loaders delegate to each other and define classes
 * with the same package name, and one such loader relies on the 
lookup

 * behavior of {@code getPackage} to return a {@code Package} from
 * a parent loader, then the properties exposed by the {@code Package}
 * may not be as expected in the rest of the program.
 * For example, the {@code Package} will only expose annotations 
from the
 * {@code package-info.class} file defined by the parent loader, 
even if

 * annotations exist in a {@code package-info.class} file defined by
 * a child loader.  Instead, use the {@link 
ClassLoader#getDefinedPackage}
 * method which only returns a {@code Package} for the specified 
class loader.

 *

Mandy

hg: jigsaw/jake/jdk: Update test/java/util/ResourceBundle/Bug6299235Test.sh to use -Xpatch

[mandy . chung]

Changeset: 9a3cd31c64df
Author:mchung
Date:  2015-10-05 18:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a3cd31c64df

Update test/java/util/ResourceBundle/Bug6299235Test.sh to use -Xpatch

! test/ProblemList.jake.txt
! test/java/util/ResourceBundle/Bug6299235Test.sh