Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

[Andrej Golovnin]

Hi Patrick,

src/java.base/share/classes/java/lang/ClassLoader.java

The constant RESOURCE_CHARACTERISTICS in the line 215 should be
defined near the #streamOf()-method. The distance between the line
1412 where the #streamOf()-method is defined and the line 215 is just
too huge.

Your patch seems to modify the JavaDocs of the methods #getParent(),
#getPlatformClassLoader(), #getSystemClassLoader(). But I don see how
it is related to the issue you try to solve.


test/java/lang/ClassLoader/resources/ResourcesFailureCase.java
test/java/lang/ClassLoader/resources/ResourcesSuccessCase.java

The indentation is broken. You use tabs. But in JDK you must use
spaces, see 
http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-indentation

Best regards,
Andrej Golovnin

On Thu, Sep 1, 2016 at 10:06 PM, Patrick Reinhart  wrote:
> Hi Alan,
> Hi Paul,
>
> Here is the first revision of the implementation based on our earlier 
> conversation.
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 
> 
>
> - Patrick

RFR 8157992: Improve jlink help message on optimization-related options

[Sundararajan Athijegannathan]

Please review http://cr.openjdk.java.net/~sundar/8157992/webrev.01/ for 
https://bugs.openjdk.java.net/browse/JDK-8157992


Thanks
-Sundar

hg: jigsaw/jake/jaxws: 2 new changesets

[mandy . chung]

Changeset: 22631824f551
Author:lana
Date:  2016-09-01 23:20 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/22631824f551

Added tag jdk-9+134 for changeset ab1d78d395d4

! .hgtags

Changeset: 64b7e64f3dbe
Author:mchung
Date:  2016-09-01 21:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/64b7e64f3dbe

Merge

hg: jigsaw/jake/nashorn: 5 new changesets

[mandy . chung]

Changeset: 5fb49fa09808
Author:sundar
Date:  2016-08-24 14:02 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5fb49fa09808

8164618: add documentation for NativeNumber and NativeBoolean
Reviewed-by: sundar
Contributed-by: srinivas.d...@oracle.com

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Functions.properties

Changeset: fe2dcb396ff4
Author:sundar
Date:  2016-08-25 22:23 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fe2dcb396ff4

8164748: Edit pad crashes when calling function
Reviewed-by: jlaskey

! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Main.java

Changeset: e05400ba9357
Author:lana
Date:  2016-08-25 22:36 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e05400ba9357

Merge


Changeset: cb00d5ef023a
Author:lana
Date:  2016-09-01 23:20 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cb00d5ef023a

Added tag jdk-9+134 for changeset e05400ba9357

! .hgtags

Changeset: 03176c9f7a69
Author:mchung
Date:  2016-09-01 21:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/03176c9f7a69

Merge

! .hgtags

hg: jigsaw/jake/langtools: 22 new changesets

[mandy . chung]

Changeset: 4b17f176d19c
Author:jjg
Date:  2016-08-22 16:32 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4b17f176d19c

8164130: Simplify doclet IOException handling
Reviewed-by: bpatel, ksrini

! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/DocType.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/FixedStringContent.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstantsSummaryWriter.java
! 
src/jdk.javadoc/share/class

hg: jigsaw/jake/jdk: 46 new changesets

[mandy . chung]

Changeset: 8e5362b5a18d
Author:igerasim
Date:  2016-08-22 22:16 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e5362b5a18d

8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input
Reviewed-by: scolebourne, ntv, coffeys

! src/java.base/share/classes/java/time/ZoneOffset.java
! test/java/time/tck/java/time/TCKZoneOffset.java

Changeset: 1a18cda712f8
Author:sdrach
Date:  2016-08-18 17:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a18cda712f8

8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned 
entries in a multi-release jar file
Reviewed-by: psandoz
Contributed-by: steve.dr...@oracle.com

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java
+ test/jdk/nio/zipfs/jarfs/JFSTester.java
+ test/jdk/nio/zipfs/jarfs/root/dir1/leaf1.txt
+ test/jdk/nio/zipfs/jarfs/root/dir1/leaf2.txt
+ test/jdk/nio/zipfs/jarfs/root/dir2/leaf3.txt
+ test/jdk/nio/zipfs/jarfs/root/dir2/leaf4.txt
+ test/jdk/nio/zipfs/jarfs/v9/root/dir1/leaf1.txt
+ test/jdk/nio/zipfs/jarfs/v9/root/dir1/leaf2.txt
+ test/jdk/nio/zipfs/jarfs/v9/root/dir2/leaf3.txt
+ test/jdk/nio/zipfs/jarfs/v9/root/dir2/leaf4.txt

Changeset: 7925851df5ff
Author:amurillo
Date:  2016-08-22 15:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7925851df5ff

8164589: Remove  sun/rmi/runtime/Log/6409194/NoConsoleOutput.java from 
ProblemList
Reviewed-by: jwilhelm

! test/ProblemList.txt

Changeset: 0cd4b4def24f
Author:darcy
Date:  2016-08-22 17:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0cd4b4def24f

8164524: Correct inconsistencies in floating-point abs spec
Reviewed-by: martin, bpb

! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java

Changeset: eeef9a64af04
Author:shurailine
Date:  2016-08-22 18:22 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eeef9a64af04

8163126: Fix @modules in some of jdk/* tests
Reviewed-by: weijun, alanb, mchung

! test/jdk/lambda/TEST.properties
! test/jdk/modules/etc/VerifyModuleDelegation.java
! test/jdk/modules/scenarios/container/ContainerTest.java
! test/jdk/nio/zipfs/MultiReleaseJarTest.java
! test/jdk/security/jarsigner/Spec.java

Changeset: b548b8217d8c
Author:rfield
Date:  2016-08-22 19:28 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b548b8217d8c

8164596: jshell tool: jdk repo module pages to allow double-dash fix to access 
Jopt-simple
Reviewed-by: jlahoda

! src/jdk.internal.opt/share/classes/module-info.java

Changeset: 6fe57070fd27
Author:lancea
Date:  2016-08-23 10:30 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6fe57070fd27

8164061: Fix @since for javax.sql.rowset.BaseRowSet and 
javax.sql.CommonDataSource
Reviewed-by: darcy

! src/java.sql.rowset/share/classes/javax/sql/rowset/BaseRowSet.java
! src/java.sql/share/classes/javax/sql/CommonDataSource.java
! src/java.sql/share/classes/javax/sql/ConnectionPoolDataSource.java
! src/java.sql/share/classes/javax/sql/DataSource.java
! src/java.sql/share/classes/javax/sql/XADataSource.java

Changeset: e160c542959b
Author:asmotrak
Date:  2016-08-23 10:32 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e160c542959b

8164592: java/net/MulticastSocket/NoLoopbackPackets.java tests may leave a 
daemon thread
Reviewed-by: clanger, chegar

! test/java/net/MulticastSocket/NoLoopbackPackets.java

Changeset: 822cc9eacd37
Author:asmotrak
Date:  2016-08-23 10:38 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/822cc9eacd37

8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon 
threads
Reviewed-by: alanb

! test/java/nio/file/WatchService/UpdateInterference.java

Changeset: 64a55ea8c804
Author:bchristi
Date:  2016-08-23 10:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64a55ea8c804

7180225: SecurityExceptions not defined in some class loader methods
Reviewed-by: mchung, mullan

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

Changeset: 5612c35465f3
Author:bpb
Date:  2016-08-23 10:51 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5612c35465f3

8164556: Drop AAC and FLAC from content type check in 
java/nio/file/Files/probeContentType/Basic.java
Summary: Remove file extensions of AAC and FLAC audio encodings from the list 
of extensions verified.
Reviewed-by: alanb

! test/java/nio/file/Files/probeContentType/Basic.java

Changeset: 48a8aec77491
Author:psandoz
Date:  2016-08-23 15:44 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48a8aec77491

8160971: Re-enable VarHandle tests quarantined by JDK-8160690
Reviewed-by: vlivanov

! test/ProblemList.txt

Changeset: 104fda852047
Author:sdrach
Date:  2016-08-23 11:26 -0700
URL:   http://hg.openjdk.j

hg: jigsaw/jake/hotspot: 4 new changesets

[mandy . chung]

Changeset: 091445016861
Author:jwilhelm
Date:  2016-08-19 17:19 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/091445016861

8164124: [BACKOUT] G1 does not implement millis_since_last_gc which is needed 
by RMI GC
Reviewed-by: jprovino

! src/share/vm/gc/g1/g1Analytics.cpp
! src/share/vm/gc/g1/g1Analytics.hpp
! src/share/vm/gc/g1/g1CollectedHeap.cpp
! src/share/vm/gc/g1/g1DefaultPolicy.cpp
! src/share/vm/gc/shared/genCollectedHeap.cpp

Changeset: b8b694c6b4d2
Author:lana
Date:  2016-08-25 22:36 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b8b694c6b4d2

Merge


Changeset: d785dfdb7bcc
Author:lana
Date:  2016-09-01 23:20 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d785dfdb7bcc

Added tag jdk-9+134 for changeset b8b694c6b4d2

! .hgtags

Changeset: 25cc45ea8cdb
Author:mchung
Date:  2016-09-01 21:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/25cc45ea8cdb

Merge

! .hgtags

hg: jigsaw/jake/jaxp: 5 new changesets

[mandy . chung]

Changeset: 4414c22d531e
Author:joehw
Date:  2016-08-23 13:33 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4414c22d531e

8157797: SAX Parser throws incorrect error on invalid xml
Reviewed-by: lancea

! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
+ test/javax/xml/jaxp/unittest/parsers/HandleError.java

Changeset: 6e7c24624fc9
Author:lana
Date:  2016-08-25 22:36 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6e7c24624fc9

Merge


Changeset: 1c6c21d87aa4
Author:joehw
Date:  2016-08-26 14:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1c6c21d87aa4

8163232: Catalog API: Consolidating CatalogResolver to support all XML Resolvers
Reviewed-by: dfuchs, lancea

! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.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/impl/XMLEntityManager.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EntityResolverWrapper.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
! 
src/java.xml/share/classes/com/sun/xml/internal/stream/StaxEntityResolverWrapper.java
! src/java.xml/share/classes/javax/xml/catalog/Catalog.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java
! src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java
- src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolver.java
- src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java
! src/java.xml/share/classes/javax/xml/catalog/Util.java
! test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java
! test/javax/xml/jaxp/functional/catalog/DefaultFeaturesTest.java
! test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java
! test/javax/xml/jaxp/functional/catalog/DelegatePublicTest.java
! test/javax/xml/jaxp/functional/catalog/DelegateSystemTest.java
! test/javax/xml/jaxp/functional/catalog/DelegateUriTest.java
! test/javax/xml/jaxp/functional/catalog/GroupTest.java
! test/javax/xml/jaxp/functional/catalog/LoadCatalogTest.java
! test/javax/xml/jaxp/functional/catalog/NextCatalogTest.java
! test/javax/xml/jaxp/functional/catalog/NormalizationTest.java
! test/javax/xml/jaxp/functional/catalog/PreferFeatureTest.java
! test/javax/xml/jaxp/functional/catalog/PreferTest.java
! test/javax/xml/jaxp/functional/catalog/PublicFamilyTest.java
! test/javax/xml/jaxp/functional/catalog/PublicTest.java
! test/javax/xml/jaxp/functional/catalog/ResolveFeatureTest.java
! test/javax/xml/jaxp/functional/catalog/RewriteSystemTest.java
! test/javax/xml/jaxp/functional/catalog/RewriteUriTest.java
! test/javax/xml/jaxp/functional/catalog/SpecifyCatalogTest.java
! test/javax/xml/jaxp/functional/catalog/SystemFamilyTest.java
! test/javax/xml/jaxp/functional/catalog/SystemSuffixTest.java
! test/javax/xml/jaxp/functional/catalog/SystemTest.java
! test/javax/xml/jaxp/functional/catalog/UriFamilyTest.java
! test/javax/xml/jaxp/functional/catalog/UriSuffixTest.java
! test/javax/xml/jaxp/functional/catalog/UriTest.java
! test/javax/xml/jaxp/functional/catalog/UrnUnwrappingTest.java
! test/javax/xml/jaxp/functional/catalog/ValidateCatalogTest.java
! test/javax/xml/jaxp/functional/catalog/catalogFiles/deferFeature.xml
! test/javax/xml/jaxp/functional/catalog/catalogFiles/uri.xml
! test/javax/xml/jaxp/functional/catalog/catalogFiles/uriFamily.xml
! test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.java
! test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java
! test/javax/xml/jaxp/libs/catalog/ResolutionChecker.java
! test/javax/xml/jaxp/unittest/catalog/CatalogSupport.java
! test/javax/xml/jaxp/unittest/catalog/CatalogSupport.xml
! test/javax/xml/jaxp/unittest/catalog/CatalogSupport1.java
! test/javax/xml/jaxp/unittest/catalog/CatalogSupport2.java
! test/javax/xml/jaxp/unittest/catalog/CatalogSupport3.java
! test/javax/xml/jaxp/unittest/catalog/CatalogSupport4.java
+ test/javax/xml/jaxp/unittest/catalog/CatalogSupport5.java
! test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java
+ test/javax/xml/jaxp/unittest/catalog/CatalogSupport_uri.xml
! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java
! test/javax/xml/jaxp/unittest/catalog/catalog.xml
+ test/javax/xml/jaxp/unittest/catalog/catalog_uri.xml
+ test/javax/xml/jaxp/unittest/catalog/delegateuri.xml
! test/javax/xml/jaxp/unittest/catalog/files/delegatecatalog.xml
+ test/javax/xml/jaxp/unittest/c

hg: jigsaw/jake: 2 new changesets

[mandy . chung]

Changeset: 7ef51cfe867e
Author:lana
Date:  2016-09-01 23:20 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7ef51cfe867e

Added tag jdk-9+134 for changeset 065724348690

! .hgtags

Changeset: 8fa615724c4f
Author:mchung
Date:  2016-09-01 21:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/8fa615724c4f

Merge

! common/autoconf/generated-configure.sh

hg: jigsaw/jake/corba: 2 new changesets

[mandy . chung]

Changeset: 094d0db606db
Author:lana
Date:  2016-09-01 23:20 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/094d0db606db

Added tag jdk-9+134 for changeset 1a497f5ca0cf

! .hgtags

Changeset: 11ceba666902
Author:mchung
Date:  2016-09-01 21:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/11ceba666902

Merge

Re: Multiple versions of a non-exported dependency

[Richard Opalka]

Reformulating the idea to make it more clear:

On 09/01/2016 06:34 PM, Richard Opalka wrote:

On 09/01/2016 03:59 PM, Alan Bateman wrote:
The issue is of course that there is lot more in picture, esp. when 
you have the unnamed module (= class path) reading all modules, also 
automatic modules that bridge to the class path (and so read the 
unnamed module). Then add upgradable modules into the picture, ... 
and you will quickly start to see there is a lot more to this, not to 
mind the risk of circular delegation. 
Trying not to hijack this thread (and yes I am aware it is maybe too 
late for Jigsaw project to change it) but I'd like to share one idea.


What if Jigsaw would work like this?
 - [A] Non-platform explicit modules (specified on --module-path) 
would support versions with loaders-per-module
 - [B] Version should be optional literal in module-info.java when 
declaring module dependencies for such modules
 - [C] UNNAMED classpath module shouldn't see non-platform explicit 
modules by default
   (users might use -XaddExports to export them explicitly with risk 
for split-package issue and other issues)


Further I can't see the real benefit of automatic modules (they read 
UNNAMED module(s) and all other explicit modules).

I am aware of two real world usecases it might solve:
 1) to workaround licensing issues of dead java projects (where 
consumers are disallowed to change them in any way)
 2) automatic module placed on --upgrade-module-path (to allow smooth 
migration for EE APIs without need to define module-info.class for them)


Considering 1) (i.e. dead wrong licensed projects should die) and 2) 
here's final proposal point:
 - [D] automatic modules would be supported only in 
--upgrade-module-path universe without possibility to read UNNAMED 
modules.
 Since upgradeable modules replace platform modules UNNAMED 
classpath module would have to read/see them.


Richard


In order for Jigsaw to support multiple module versions

(not saying it should do so, just reasoning about it)

the following steps would be necessary:

 * Disconnect Modularized world from Classpath world (eliminate 
automatic modules)


 * All platform provided modules would be "unversioned" and unique 
(they'd have implicit platform version, e.g. 9-ea)


 * Separate graphs of "user provided explicit modules universe" 
(provided via --module-path option) from "platform modules universe" 
(provided in JDK image)


 * User provided explicit modules would support multiple versions via 
loader-per-module (including explicit module version string in 
module-info.java)


 * Update module-info.java format to allow both to specify explicit 
module version and to allow dependencies on explicit module versions 
(e.g. "requires module.foo 1.0)


 * "requires public" would be disallowed for explicitly versioned modules

 * Update module graph mapping to the VM to take module version string 
into account



Richard

RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

[Patrick Reinhart]

Hi Alan,
Hi Paul,

Here is the first revision of the implementation based on our earlier 
conversation.

http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 


- Patrick

Re: Multiple versions of a non-exported dependency

[cowwoc]

Another possibility (not saying it's better, just putting it out there) 
is to do the following:

 1. Provide a tool like "javah" that would generate module-info.java for
non-modularized JAR files.
 2. Provide a mechanism to "glue" the generated module-info files to the
original non-modularized JAR files without modification (as if the
files were inside the JAR file, but they aren't).
 3. Developers could use the generated templates as-is or customize them
further after generation.

This way everything would be a real module and you'd get extra 
customization that is currently not available with automatic modules. 
This process moves the "glue" from runtime to package-time.

Gili

On 2016-09-01 3:34 PM, Richard Opalka [via jigsaw-dev] wrote:
> On 09/01/2016 06:58 PM, Alan Bateman wrote:
>
> > On 01/09/2016 17:34, Richard Opalka wrote:
> > Further I can't see the real benefit of automatic modules (they read
> > UNNAMED module(s) and all other explicit modules).
> >> I am aware of two real world usecases it might solve:
> >>  1) to workaround licensing issues of dead java projects (where
> >> consumers are disallowed to change them in any way)
> >>  2) automatic module placed on --upgrade-module-path (to allow smooth
> >> migration for EE APIs without need to define module-info.class for 
> them)
> > Automatic modules facilitate top-level migration, you can migrate to
> > modules without waiting for everything that you transitively depend to
> > migrate. They also allow bridging to the class path - say where you
> > move just your direct dependences while leaving the rest on the class
> > path. The topic is covered in the STOMS [1] and also in the Advanced
> > Modularity talks at JavaOne and Devoxx last year [2].
> >
> > -Alan
> >
> > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
> > [1] http://openjdk.java.net/projects/jigsaw/talks/
> Yes, I'm familiar and aware of these. What I meant is:
>
> Is the benefit of incremental migration (automatic modules provide) that
> valuable?
> What's bad with "modularize all or nothing" kind of migration?
> There would be no need for bridges to the classpath if automatic modules
> would disappear.
>
> Richard
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713397.html
>  
>
> To unsubscribe from Multiple versions of a non-exported dependency, 
> click here 
> .
> NAML 
> 
>  
>






--
View this message in context: 
http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713398.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.

Re: Multiple versions of a non-exported dependency

[Richard Opalka]

On 09/01/2016 06:58 PM, Alan Bateman wrote:

On 01/09/2016 17:34, Richard Opalka wrote:
Further I can't see the real benefit of automatic modules (they read 
UNNAMED module(s) and all other explicit modules).

I am aware of two real world usecases it might solve:
 1) to workaround licensing issues of dead java projects (where 
consumers are disallowed to change them in any way)
 2) automatic module placed on --upgrade-module-path (to allow smooth 
migration for EE APIs without need to define module-info.class for them)
Automatic modules facilitate top-level migration, you can migrate to 
modules without waiting for everything that you transitively depend to 
migrate. They also allow bridging to the class path - say where you 
move just your direct dependences while leaving the rest on the class 
path. The topic is covered in the STOMS [1] and also in the Advanced 
Modularity talks at JavaOne and Devoxx last year [2].


-Alan

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
[1] http://openjdk.java.net/projects/jigsaw/talks/

Yes, I'm familiar and aware of these. What I meant is:

Is the benefit of incremental migration (automatic modules provide) that 
valuable?

What's bad with "modularize all or nothing" kind of migration?
There would be no need for bridges to the classpath if automatic modules 
would disappear.


Richard

Re: Multiple versions of a non-exported dependency

[Alan Bateman]

On 01/09/2016 15:35, David M. Lloyd wrote:



Yeah having the class path remain on the legacy application class 
loader is demonstrably better for interop.  But new modules?  Does 
that make sense?
Yes, specifically automatic modules where a JAR file is moved from the 
class path to module path without any changes. Also any library that is 
migrated to an explicit module. If the library is used to being on the 
class path today, and it's not in a world of hurt that is split packages 
or cycles, then the effort to make it an explicit module might be minimal.



:

Anyway using interoperability as an argument is very weak as long as 
"export dynamic *" or any variation thereof is considered to be an 
acceptable solution to #ReflectiveAccessToNonExportedTypes.  In order 
to have proper interoperability for any reflection-using or reflected 
module, you have to do this, which defeats the primary security 
measure of modules.  Isn't this a much more likely interop problem 
than putting modules (something that never existed before) into their 
own class loaders?


Modules might be new but a lot existing code that will be migrated. I 
don't wish to engage on the #ReflectiveAccessToNonExportedTypes topic in 
this thread, mostly because that topic is still open on the JSR list and 
there are several overlapping threads already.


-Alan

Re: Multiple versions of a non-exported dependency

[Alan Bateman]

On 01/09/2016 17:34, Richard Opalka wrote:



 - [C] UNNAMED classpath module shouldn't see non-platform explicit 
modules by default
   (users might use -XaddExports to export them explicitly with risk 
for split-package issue and other issues)
That is how it works, except you use --add-modules to ensure that any 
needed modules on the module path are resolved.




Further I can't see the real benefit of automatic modules (they read 
UNNAMED module(s) and all other explicit modules).

I am aware of two real world usecases it might solve:
 1) to workaround licensing issues of dead java projects (where 
consumers are disallowed to change them in any way)
 2) automatic module placed on --upgrade-module-path (to allow smooth 
migration for EE APIs without need to define module-info.class for them)
Automatic modules facilitate top-level migration, you can migrate to 
modules without waiting for everything that you transitively depend to 
migrate. They also allow bridging to the class path - say where you move 
just your direct dependences while leaving the rest on the class path. 
The topic is covered in the STOMS [1] and also in the Advanced 
Modularity talks at JavaOne and Devoxx last year [2].


-Alan

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
[1] http://openjdk.java.net/projects/jigsaw/talks/

Re: Multiple versions of a non-exported dependency

[Richard Opalka]

On 09/01/2016 03:59 PM, Alan Bateman wrote:
The issue is of course that there is lot more in picture, esp. when 
you have the unnamed module (= class path) reading all modules, also 
automatic modules that bridge to the class path (and so read the 
unnamed module). Then add upgradable modules into the picture, ... and 
you will quickly start to see there is a lot more to this, not to mind 
the risk of circular delegation. 
Trying not to hijack this thread (and yes I am aware it is maybe too 
late for Jigsaw project to change it) but I'd like to share one idea.


What if Jigsaw would work like this?
 - [A] Non-platform explicit modules (specified on --module-path) would 
support versions with loaders-per-module
 - [B] Version should be optional literal in module-info.java when 
declaring module dependencies for such modules
 - [C] UNNAMED classpath module shouldn't see non-platform explicit 
modules by default
   (users might use -XaddExports to export them explicitly with risk 
for split-package issue and other issues)


Further I can't see the real benefit of automatic modules (they read 
UNNAMED module(s) and all other explicit modules).

I am aware of two real world usecases it might solve:
 1) to workaround licensing issues of dead java projects (where 
consumers are disallowed to change them in any way)
 2) automatic module placed on --upgrade-module-path (to allow smooth 
migration for EE APIs without need to define module-info.class for them)


Considering 1) (i.e. dead wrong licensed projects should die) and 2) 
here's final proposal point:
 - [D] automatic modules would be supported only in 
--upgrade-module-path universe without possibility to read UNNAMED modules.
 Since upgradeable modules replace platform modules UNNAMED 
classpath module would have to read/see them.


Richard

Re: Multiple versions of a non-exported dependency

[Gregg Wonderly]

Trying not to distract this conversation away from the details…  In the end, 
the concept of “micro services” and things like “Jini” discovery can allow 
smaller distribution of systems in single class loaders without conflicts.   
But still, there is the static data design issue.  I have a Jini discovery 
based desktop application that I’ve used for more than a decade to “find” 
services on my network, download their proxy and associated UI, and use them.   
Those applications are all separate class loaders and do not interact inside of 
my desktop application.  If they need to interact, they do so via their 
services which interact with other services through discovery of that service, 
download of the proxy and calls out through the jointly know interface/class 
name which was used in the lookup criteria.   All of this has explicit version 
management because the Jar file names are well known and include version 
numbers in them.

In Jini, there is a lot of class loading happening with downloaded code, but it 
is a well formed tree structure inside of my desktop application because each 
application is using a specific version of jars in its setting of the exported 
class details. 

Jigsaw is orthogonal to what I am doing with Jini because Jigsaw is about 
starting the application, not extending the application as the Jini discovery 
and downloads do.  However, I am trying to point out how the direct references 
to version details in the design and operation of the system allow for multiple 
versions to coexist trivially and be managed explicitly to help the system 
continue to function correctly.   

If I have an application deployed twice, with two different sets of jars 
because of version changes, and my desktop application picks one of them at 
random to use, it won’t matter if I in fact try to open both instances by 
explicitly knowing how to do that because the class loader design keeps them 
separated and the exported class loader detail identifies the specifics need to 
make each function as a separate application within my desktop container.

I don’t know what base of users and what paradigms of deployments the Jigsaw 
team considered.  It’s clear that they focused first on modularity of the JVM.  
It’s not obvious that how other module systems unrelated to pluggable 
functionality that the JVM is trying to separate were considered.  The 
separation of detail that is not referenced is a simple modularization detail.  
The isolation of detail that should not be referenced is a different 
modularization detail which just doesn’t seem to be completely considered for 
any detail other than “exposure” as opposed to “compatibility” which is what 
“Version” points to.

Gregg


> On Sep 1, 2016, at 10:12 AM, Gregg Wonderly  wrote:
> 
> Why I was referring to is how will modules find classes from other modules?  
> How will the different version of the same package namespace that Gili was 
> talking about be hidden?   In other words, you can only make them all visible 
> by using a single class loader, unless there is a DAG of dependencies that 
> naturally falls out, because all we have is ClassLoaders parent as the 
> pointer to other interesting detail.
> 
> How will definedModulesWithManyLoaders make it possible for all of the 
> correct details to be visible? 
> 
> Some explicit example detail:
> 
> module A uses l4j logging in module B
> 
> module C uses l4j logging in module D
> 
> module E is a standalone module
> 
> A and C exchange data objects defined in E
> 
> +— B — A
> |
> + E
> |
> +— D — C
> 
> This graph you can draw today with ClassLoader parent references.   But, 
> there are more complicated graphs that fall out from less simple needs.  It’s 
> this specific issue of still not trying to provide support for versions and 
> for arranging the module dependencies more explicitly through the use of 
> version as part of the package name namespace which Gili is trying to speak 
> to I feel.
> 
> Since B and D are the same package name, you have to hide them from each 
> other in separate class loaders, obviously.   But the Graph from C to E and A 
> to E is not always direct and can in some cases not be possible with a single 
> instance of the jar.  That breaks static class data designs if you create two 
> copies in separate loaders.
> 
> Gregg
> 
>> On Sep 1, 2016, at 8:37 AM, David M. Lloyd  wrote:
>> 
>> You've missed the point I'm afraid.  I'm just talking about having the 
>> launcher use (the equivalent of) 
>> java.lang.reflect.Layer#defineModulesWithManyLoaders instead of (the 
>> equivalent of) java.lang.reflect.Layer#defineModulesWithOneLoader.  (The 
>> launcher actually uses the slightly lower level defineModules() method I 
>> think, but really what I'm suggesting is to update the function to assign 
>> new class loaders for named modules instead of reusing the same one.)
>> 
>> On 09/01/2016 08:23 AM, Gregg Wonderly wrote:
>>> The important detail for me, is that ClassLoad

Re: Multiple versions of a non-exported dependency

[Gregg Wonderly]

Why I was referring to is how will modules find classes from other modules?  
How will the different version of the same package namespace that Gili was 
talking about be hidden?   In other words, you can only make them all visible 
by using a single class loader, unless there is a DAG of dependencies that 
naturally falls out, because all we have is ClassLoaders parent as the pointer 
to other interesting detail.

How will definedModulesWithManyLoaders make it possible for all of the correct 
details to be visible? 

Some explicit example detail:

module A uses l4j logging in module B

module C uses l4j logging in module D

module E is a standalone module

A and C exchange data objects defined in E

+— B — A
 |
+ E
 |
 +— D — C

This graph you can draw today with ClassLoader parent references.   But, there 
are more complicated graphs that fall out from less simple needs.  It’s this 
specific issue of still not trying to provide support for versions and for 
arranging the module dependencies more explicitly through the use of version as 
part of the package name namespace which Gili is trying to speak to I feel.

Since B and D are the same package name, you have to hide them from each other 
in separate class loaders, obviously.   But the Graph from C to E and A to E is 
not always direct and can in some cases not be possible with a single instance 
of the jar.  That breaks static class data designs if you create two copies in 
separate loaders.

Gregg

> On Sep 1, 2016, at 8:37 AM, David M. Lloyd  wrote:
> 
> You've missed the point I'm afraid.  I'm just talking about having the 
> launcher use (the equivalent of) 
> java.lang.reflect.Layer#defineModulesWithManyLoaders instead of (the 
> equivalent of) java.lang.reflect.Layer#defineModulesWithOneLoader.  (The 
> launcher actually uses the slightly lower level defineModules() method I 
> think, but really what I'm suggesting is to update the function to assign new 
> class loaders for named modules instead of reusing the same one.)
> 
> On 09/01/2016 08:23 AM, Gregg Wonderly wrote:
>> The important detail for me, is that ClassLoader per module, with the 
>> current Class resolution scheme (this ClassLoader and whatever I can find in 
>> the parent), provides a lot of issues. The “custom ClassLoaders” or 
>> “containers like OSGi” remarks point at the “us and them” attitude that is 
>> pretty prevalent in this conversation.  The majority of developers are 
>> looking for a module system that is not an “us or them” proposition.   These 
>> “all or nothing” compromises are what create the “hell” that dominates 
>> conversations here.  What we all want to be able to do, is write software 
>> once, target it to “THE Java platform”, and be done.
>> 
>> What Sun and now Oracle are continuing to do, is create more stuff that is 
>> nothing like what everyone else is doing with modularity and instead create 
>> something that is orthogonal to most peoples problem spaces and in the end 
>> creates tremendously more “work” for nothing more than compatibility with 
>> the new “JVM” environment.
>> 
>> The real goal here needs to be making all of the other module and container 
>> systems obsolete.  Those systems should “want” to provide support for the 
>> awesome, new module system that will make in unnecessary for them to roll 
>> their own details any longer.
>> 
>> Yes, that is a long road and a tall measure for success.  But frankly, even 
>> the lack of any visibility of the style of modules that Netbeans has used 
>> for decades makes it clear that this groups view at Oracle is extremely 
>> narrow and perhaps even more uninformed about what the community actually 
>> needs.
>> 
>> Gregg
>> 
>>> On Sep 1, 2016, at 7:29 AM, David M. Lloyd  wrote:
>>> 
>>> It seems like there is no good reason why the application modules aren't 
>>> loaded with classloader-per-module now.  The platform stuff could all be in 
>>> one, but the application stuff?  Problems like this are going to come up a 
>>> lot otherwise; let's consider making that change.
>>> 
>>> On 08/31/2016 07:45 PM, Neil Bartlett wrote:
 Remi,
 
 Actually I don’t think that statically linking will work. This would 
 produce modules that have overlapping private (non-exported) packages, and 
 such modules also cannot be used in Java 9 on the modulepath.
 
 I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating 
 two modules both containing a private package org.example.util. The 
 following exception resulted:  
 java.lang.reflect.LayerInstantiationException: Package org.example.util in 
 both module a and module b.
 
 Again this could be “solved” by using custom ClassLoaders or a 
 ClassLoader-based module system like OSGi on Java 9.
 
 Neil
 
 
 
> On 31 Aug 2016, at 20:28, Remi Forax  wrote:
> 
> The other solution is to statically link the right version of slf4j 
> inside guava and jsoup.
>

Re: Multiple versions of a non-exported dependency

[David M. Lloyd]

On 09/01/2016 08:59 AM, Alan Bateman wrote:

On 01/09/2016 13:29, David M. Lloyd wrote:


It seems like there is no good reason why the application modules
aren't loaded with classloader-per-module now.  The platform stuff
could all be in one, but the application stuff?  Problems like this
are going to come up a lot otherwise; let's consider making that change.

If we were just dealing with a graph of explicit modules they it may be
an option, assuming you get over all the issues that arise when
arranging visibility this way. You might remember "module mode" in the
original exploratory phase of Project Jigsaw for example.

The issue is of course that there is lot more in picture, esp. when you
have the unnamed module (= class path) reading all modules, also
automatic modules that bridge to the class path (and so read the unnamed
module). Then add upgradable modules into the picture, ... and you will
quickly start to see there is a lot more to this, not to mind the risk
of circular delegation.


Risk?  If the modules don't have circular delegation then the class 
loaders won't; but anyway I don't understand *at all* why circular 
delegation in class loaders is a problem (we do this today and it has 
worked great since Java 7, and there's no particular magic necessary to 
do so).  And in any event circular delegation in modules *should* be 
allowed, full stop; there's no good reason not to allow it (especially 
given the very-super-eager-loading behavior of module layers).  Again we 
do this today and it's fine.



So I think what we have ended up with sane and not difficult to explain.
It favors migration and good interop over green field.


Yeah having the class path remain on the legacy application class loader 
is demonstrably better for interop.  But new modules?  Does that make sense?



Sure, there will
be periodic complaints when people try to deploy modules with
overlapping packages on the application module path. Anyone using Maven
Shade Plugin and the like can continue to do this. Finally, it's not
hard to create your own "launcher" that instantiates the configuration
with Layer.defineModulesWithManyLoaders if you really want.


I think many people will do this.  The benefits of modules are 
diminishing if you don't actually get this level of isolation by 
default.  And I think that it's much harder to imagine a real interop 
problem that could arise from it than it is to imagine a real problem 
that will occur from not doing it.


Anyway using interoperability as an argument is very weak as long as 
"export dynamic *" or any variation thereof is considered to be an 
acceptable solution to #ReflectiveAccessToNonExportedTypes.  In order to 
have proper interoperability for any reflection-using or reflected 
module, you have to do this, which defeats the primary security measure 
of modules.  Isn't this a much more likely interop problem than putting 
modules (something that never existed before) into their own class loaders?


--
- DML

Re: Multiple versions of a non-exported dependency

[cowwoc]

> What Sun and now Oracle are continuing to do, is create more stuff 
> that is nothing like what everyone else is doing with modularity and 
> instead create something that is orthogonal to most peoples problem 
> spaces and in the end creates tremendously more “work” for nothing 
> more than compatibility with the new “JVM” environment.

A big +1. The cost/benefit of Jigsaw without version-awareness is very 
poor for end-users.

Our long-term goal should be to "import" the best ideas from existing 
module systems in the Java platform over time. No one is expecting you 
to do this from day one, but the fact that "requires" does not take a 
constant version number from day one prevents this kind of evolution 
from ever taking place.

On 2016-09-01 10:00 AM, Alan Bateman [via jigsaw-dev] wrote:
> So I think what we have ended up with sane and not difficult to explain.
> It favors migration and good interop over green field. Sure, there will
> be periodic complaints when people try to deploy modules with
> overlapping packages on the application module path. Anyone using Maven
> Shade Plugin and the like can continue to do this. Finally, it's not
> hard to create your own "launcher" that instantiates the configuration
> with Layer.defineModulesWithManyLoaders if you really want. 

It would help if you could publish a sample "launcher" to show people 
how easy it really is. This won't resolve my outstanding problem with 
the specification (lack of a version number in "requires") but at least 
then we can move the discussion to whether a (simple) concrete 
implementation is able to do what we want.

Gili

On 2016-09-01 9:24 AM, Gregg Wonderly [via jigsaw-dev] wrote:
> The important detail for me, is that ClassLoader per module, with the 
> current Class resolution scheme (this ClassLoader and whatever I can 
> find in the parent), provides a lot of issues. The “custom 
> ClassLoaders” or “containers like OSGi” remarks point at the “us and 
> them” attitude that is pretty prevalent in this conversation.  The 
> majority of developers are looking for a module system that is not an 
> “us or them” proposition.   These “all or nothing” compromises are 
> what create the “hell” that dominates conversations here.  What we all 
> want to be able to do, is write software once, target it to “THE Java 
> platform”, and be done.
>
> What Sun and now Oracle are continuing to do, is create more stuff 
> that is nothing like what everyone else is doing with modularity and 
> instead create something that is orthogonal to most peoples problem 
> spaces and in the end creates tremendously more “work” for nothing 
> more than compatibility with the new “JVM” environment.
>
> The real goal here needs to be making all of the other module and 
> container systems obsolete.  Those systems should “want” to provide 
> support for the awesome, new module system that will make in 
> unnecessary for them to roll their own details any longer.
>
> Yes, that is a long road and a tall measure for success.  But frankly, 
> even the lack of any visibility of the style of modules that Netbeans 
> has used for decades makes it clear that this groups view at Oracle is 
> extremely narrow and perhaps even more uninformed about what the 
> community actually needs.
>
> Gregg
>
> > On Sep 1, 2016, at 7:29 AM, David M. Lloyd <[hidden email] 
> > wrote:
> >
> > It seems like there is no good reason why the application modules 
> aren't loaded with classloader-per-module now.  The platform stuff 
> could all be in one, but the application stuff?  Problems like this 
> are going to come up a lot otherwise; let's consider making that change.
> >
> > On 08/31/2016 07:45 PM, Neil Bartlett wrote:
> >> Remi,
> >>
> >> Actually I don’t think that statically linking will work. This 
> would produce modules that have overlapping private (non-exported) 
> packages, and such modules also cannot be used in Java 9 on the 
> modulepath.
> >>
> >> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by 
> creating two modules both containing a private package 
> org.example.util. The following exception resulted: 
>  java.lang.reflect.LayerInstantiationException: Package 
> org.example.util in both module a and module b.
> >>
> >> Again this could be “solved” by using custom ClassLoaders or a 
> ClassLoader-based module system like OSGi on Java 9.
> >>
> >> Neil
> >>
> >>
> >>
> >>> On 31 Aug 2016, at 20:28, Remi Forax <[hidden email] 
> > wrote:
> >>>
> >>> The other solution is to statically link the right version of 
> slf4j inside guava and jsoup.
> >>> A tool like jarjar can be updated to merge two modular jars (merge 
> two module-info).
> >>>
> >>> cheers,
> >>> Rémi
> >>>
> >>> - Mail original -
>  De: "Neil Bartlett" <[hidden email] 
> >
>  À: [hidden email] 
> , "Alex Buckley" 
> <[hidden email] >
>  Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email] 
> >
>  Envoyé: Mercredi 31 Août 2016 20:54:44
>  Objet: Re: Multipl

Re: Multiple versions of a non-exported dependency

[Alan Bateman]

On 01/09/2016 13:29, David M. Lloyd wrote:

It seems like there is no good reason why the application modules 
aren't loaded with classloader-per-module now.  The platform stuff 
could all be in one, but the application stuff?  Problems like this 
are going to come up a lot otherwise; let's consider making that change. 
If we were just dealing with a graph of explicit modules they it may be 
an option, assuming you get over all the issues that arise when 
arranging visibility this way. You might remember "module mode" in the 
original exploratory phase of Project Jigsaw for example.


The issue is of course that there is lot more in picture, esp. when you 
have the unnamed module (= class path) reading all modules, also 
automatic modules that bridge to the class path (and so read the unnamed 
module). Then add upgradable modules into the picture, ... and you will 
quickly start to see there is a lot more to this, not to mind the risk 
of circular delegation.


So I think what we have ended up with sane and not difficult to explain. 
It favors migration and good interop over green field. Sure, there will 
be periodic complaints when people try to deploy modules with 
overlapping packages on the application module path. Anyone using Maven 
Shade Plugin and the like can continue to do this. Finally, it's not 
hard to create your own "launcher" that instantiates the configuration 
with Layer.defineModulesWithManyLoaders if you really want.


-Alan

Re: Multiple versions of a non-exported dependency

[David M. Lloyd]

You've missed the point I'm afraid.  I'm just talking about having the 
launcher use (the equivalent of) 
java.lang.reflect.Layer#defineModulesWithManyLoaders instead of (the 
equivalent of) java.lang.reflect.Layer#defineModulesWithOneLoader.  (The 
launcher actually uses the slightly lower level defineModules() method I 
think, but really what I'm suggesting is to update the function to 
assign new class loaders for named modules instead of reusing the same one.)


On 09/01/2016 08:23 AM, Gregg Wonderly wrote:

The important detail for me, is that ClassLoader per module, with the current 
Class resolution scheme (this ClassLoader and whatever I can find in the 
parent), provides a lot of issues. The “custom ClassLoaders” or “containers 
like OSGi” remarks point at the “us and them” attitude that is pretty prevalent 
in this conversation.  The majority of developers are looking for a module 
system that is not an “us or them” proposition.   These “all or nothing” 
compromises are what create the “hell” that dominates conversations here.  What 
we all want to be able to do, is write software once, target it to “THE Java 
platform”, and be done.

What Sun and now Oracle are continuing to do, is create more stuff that is 
nothing like what everyone else is doing with modularity and instead create 
something that is orthogonal to most peoples problem spaces and in the end 
creates tremendously more “work” for nothing more than compatibility with the 
new “JVM” environment.

The real goal here needs to be making all of the other module and container 
systems obsolete.  Those systems should “want” to provide support for the 
awesome, new module system that will make in unnecessary for them to roll their 
own details any longer.

Yes, that is a long road and a tall measure for success.  But frankly, even the 
lack of any visibility of the style of modules that Netbeans has used for 
decades makes it clear that this groups view at Oracle is extremely narrow and 
perhaps even more uninformed about what the community actually needs.

Gregg


On Sep 1, 2016, at 7:29 AM, David M. Lloyd  wrote:

It seems like there is no good reason why the application modules aren't loaded 
with classloader-per-module now.  The platform stuff could all be in one, but 
the application stuff?  Problems like this are going to come up a lot 
otherwise; let's consider making that change.

On 08/31/2016 07:45 PM, Neil Bartlett wrote:

Remi,

Actually I don’t think that statically linking will work. This would produce 
modules that have overlapping private (non-exported) packages, and such modules 
also cannot be used in Java 9 on the modulepath.

I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two 
modules both containing a private package org.example.util. The following 
exception resulted:  java.lang.reflect.LayerInstantiationException: Package 
org.example.util in both module a and module b.

Again this could be “solved” by using custom ClassLoaders or a 
ClassLoader-based module system like OSGi on Java 9.

Neil




On 31 Aug 2016, at 20:28, Remi Forax  wrote:

The other solution is to statically link the right version of slf4j inside 
guava and jsoup.
A tool like jarjar can be updated to merge two modular jars (merge two 
module-info).

cheers,
Rémi

- Mail original -

De: "Neil Bartlett" 
À: cow...@bbs.darktech.org, "Alex Buckley" 
Cc: "ZML-OpenJDK-Jigsaw-Developers" 
Envoyé: Mercredi 31 Août 2016 20:54:44
Objet: Re: Multiple versions of a non-exported dependency



Gili,

As Alex points out: your use-case can be supported in Java 9 but only with the
addition of custom ClassLoaders, or by using an existing ClassLoader-based
module system such as OSGi.

The same is also true of Java 8, and Java 7, etc.

Regards,
Neil



On 31 Aug 2016, at 19:29, Alex Buckley  wrote:

On 8/31/2016 10:56 AM, cowwoc wrote:

I recently became aware of the fact that the Jigsaw specification declared
"version-selection" as a non-goal. While I understand how we ended up here,
I am hoping that you were able to support the following (very common)
use-case:

* Module "HelloWorld" depends on modules "Guava" and "JSoup".
* Module "Guava" depends on module slf4j version 1 (requires but does not
export it).
* Module "JSoup" depends on module slf4j version 2 (requires but does not
export it).
* slf4j version 2 and is not backwards-compatible with version 1.

What happens at runtime? Will Jigsaw (out of the box, without 3rd-party
tools like Maven or OSGI) be smart enough to provide different versions of
slf4j to "Guava" and "JSoup"?


(You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it
a.k.a. 'requires public'.)

This use case isn't possible on JDK 8 for JARs on the classpath, and it's not
supported on JDK 9 for modular JARs on the modulepath:

- If you have two versions of a modular JAR slf4j.jar in different directories
on the modulepath, then the first one to be found will dominate, and that's
what will be 

Re: Multiple versions of a non-exported dependency

[Gregg Wonderly]

The important detail for me, is that ClassLoader per module, with the current 
Class resolution scheme (this ClassLoader and whatever I can find in the 
parent), provides a lot of issues. The “custom ClassLoaders” or “containers 
like OSGi” remarks point at the “us and them” attitude that is pretty prevalent 
in this conversation.  The majority of developers are looking for a module 
system that is not an “us or them” proposition.   These “all or nothing” 
compromises are what create the “hell” that dominates conversations here.  What 
we all want to be able to do, is write software once, target it to “THE Java 
platform”, and be done.

What Sun and now Oracle are continuing to do, is create more stuff that is 
nothing like what everyone else is doing with modularity and instead create 
something that is orthogonal to most peoples problem spaces and in the end 
creates tremendously more “work” for nothing more than compatibility with the 
new “JVM” environment.

The real goal here needs to be making all of the other module and container 
systems obsolete.  Those systems should “want” to provide support for the 
awesome, new module system that will make in unnecessary for them to roll their 
own details any longer.

Yes, that is a long road and a tall measure for success.  But frankly, even the 
lack of any visibility of the style of modules that Netbeans has used for 
decades makes it clear that this groups view at Oracle is extremely narrow and 
perhaps even more uninformed about what the community actually needs.

Gregg

> On Sep 1, 2016, at 7:29 AM, David M. Lloyd  wrote:
> 
> It seems like there is no good reason why the application modules aren't 
> loaded with classloader-per-module now.  The platform stuff could all be in 
> one, but the application stuff?  Problems like this are going to come up a 
> lot otherwise; let's consider making that change.
> 
> On 08/31/2016 07:45 PM, Neil Bartlett wrote:
>> Remi,
>> 
>> Actually I don’t think that statically linking will work. This would produce 
>> modules that have overlapping private (non-exported) packages, and such 
>> modules also cannot be used in Java 9 on the modulepath.
>> 
>> I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating 
>> two modules both containing a private package org.example.util. The 
>> following exception resulted:  
>> java.lang.reflect.LayerInstantiationException: Package org.example.util in 
>> both module a and module b.
>> 
>> Again this could be “solved” by using custom ClassLoaders or a 
>> ClassLoader-based module system like OSGi on Java 9.
>> 
>> Neil
>> 
>> 
>> 
>>> On 31 Aug 2016, at 20:28, Remi Forax  wrote:
>>> 
>>> The other solution is to statically link the right version of slf4j inside 
>>> guava and jsoup.
>>> A tool like jarjar can be updated to merge two modular jars (merge two 
>>> module-info).
>>> 
>>> cheers,
>>> Rémi
>>> 
>>> - Mail original -
 De: "Neil Bartlett" 
 À: cow...@bbs.darktech.org, "Alex Buckley" 
 Cc: "ZML-OpenJDK-Jigsaw-Developers" 
 Envoyé: Mercredi 31 Août 2016 20:54:44
 Objet: Re: Multiple versions of a non-exported dependency
>>> 
 Gili,
 
 As Alex points out: your use-case can be supported in Java 9 but only with 
 the
 addition of custom ClassLoaders, or by using an existing ClassLoader-based
 module system such as OSGi.
 
 The same is also true of Java 8, and Java 7, etc.
 
 Regards,
 Neil
 
 
> On 31 Aug 2016, at 19:29, Alex Buckley  wrote:
> 
> On 8/31/2016 10:56 AM, cowwoc wrote:
>> I recently became aware of the fact that the Jigsaw specification 
>> declared
>> "version-selection" as a non-goal. While I understand how we ended up 
>> here,
>> I am hoping that you were able to support the following (very common)
>> use-case:
>> 
>> * Module "HelloWorld" depends on modules "Guava" and "JSoup".
>> * Module "Guava" depends on module slf4j version 1 (requires but does not
>> export it).
>> * Module "JSoup" depends on module slf4j version 2 (requires but does not
>> export it).
>> * slf4j version 2 and is not backwards-compatible with version 1.
>> 
>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party
>> tools like Maven or OSGI) be smart enough to provide different versions 
>> of
>> slf4j to "Guava" and "JSoup"?
> 
> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" 
> it
> a.k.a. 'requires public'.)
> 
> This use case isn't possible on JDK 8 for JARs on the classpath, and it's 
> not
> supported on JDK 9 for modular JARs on the modulepath:
> 
> - If you have two versions of a modular JAR slf4j.jar in different 
> directories
> on the modulepath, then the first one to be found will dominate, and 
> that's
> what will be resolved for both Guava and JSoup.
> 
> - If you have two modular JARs 

Re: Multiple versions of a non-exported dependency

[David M. Lloyd]

It seems like there is no good reason why the application modules aren't 
loaded with classloader-per-module now.  The platform stuff could all be 
in one, but the application stuff?  Problems like this are going to come 
up a lot otherwise; let's consider making that change.


On 08/31/2016 07:45 PM, Neil Bartlett wrote:

Remi,

Actually I don’t think that statically linking will work. This would produce 
modules that have overlapping private (non-exported) packages, and such modules 
also cannot be used in Java 9 on the modulepath.

I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two 
modules both containing a private package org.example.util. The following 
exception resulted:  java.lang.reflect.LayerInstantiationException: Package 
org.example.util in both module a and module b.

Again this could be “solved” by using custom ClassLoaders or a 
ClassLoader-based module system like OSGi on Java 9.

Neil




On 31 Aug 2016, at 20:28, Remi Forax  wrote:

The other solution is to statically link the right version of slf4j inside 
guava and jsoup.
A tool like jarjar can be updated to merge two modular jars (merge two 
module-info).

cheers,
Rémi

- Mail original -

De: "Neil Bartlett" 
À: cow...@bbs.darktech.org, "Alex Buckley" 
Cc: "ZML-OpenJDK-Jigsaw-Developers" 
Envoyé: Mercredi 31 Août 2016 20:54:44
Objet: Re: Multiple versions of a non-exported dependency



Gili,

As Alex points out: your use-case can be supported in Java 9 but only with the
addition of custom ClassLoaders, or by using an existing ClassLoader-based
module system such as OSGi.

The same is also true of Java 8, and Java 7, etc.

Regards,
Neil



On 31 Aug 2016, at 19:29, Alex Buckley  wrote:

On 8/31/2016 10:56 AM, cowwoc wrote:

I recently became aware of the fact that the Jigsaw specification declared
"version-selection" as a non-goal. While I understand how we ended up here,
I am hoping that you were able to support the following (very common)
use-case:

* Module "HelloWorld" depends on modules "Guava" and "JSoup".
* Module "Guava" depends on module slf4j version 1 (requires but does not
export it).
* Module "JSoup" depends on module slf4j version 2 (requires but does not
export it).
* slf4j version 2 and is not backwards-compatible with version 1.

What happens at runtime? Will Jigsaw (out of the box, without 3rd-party
tools like Maven or OSGI) be smart enough to provide different versions of
slf4j to "Guava" and "JSoup"?


(You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it
a.k.a. 'requires public'.)

This use case isn't possible on JDK 8 for JARs on the classpath, and it's not
supported on JDK 9 for modular JARs on the modulepath:

- If you have two versions of a modular JAR slf4j.jar in different directories
on the modulepath, then the first one to be found will dominate, and that's
what will be resolved for both Guava and JSoup.

- If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the modulepath,
and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java
-m HelloWorld' will fail. The boot layer will refuse to map the "same" packages
from different slf4j_v* modules to the application class loader.

The use case _is_ supported on JDK 9 for modular JARs loaded into custom loaders
of custom layers. That is, the Java Platform Module System is perfectly capable
of supporting the use case -- please see any of my "Jigsaw: Under The Hood"
presentations. The use case just isn't supported "out of the box" by the 'java'
launcher for JARs on the modulepath.

Alex




--
- DML

Re: Multiple versions of a non-exported dependency

[Alan Bateman]

On 01/09/2016 08:28, Neil Bartlett wrote:


:
In contrast, Jigsaw/JPMS implements isolation using access control rather than 
ClassLoader visibility. All modules on the modulepath are loaded into the same 
ClassLoader, and a single ClassLoader can have at most one definition of each 
class. The implication is that two modules can conflict purely based on their 
private internals. If any tool attempts to construct valid module sets for use 
with the modulepath, it will not be sufficient for that tool to examine only 
the declared module metadata in module-info.class.
Tools or containers that are looking at module declarations will need to 
be concerned with the non-exported packages, even if each module is 
ultimately mapped to its own class loader (easy to do with Layer API, no 
need to get into creating custom class loaders). Specifically, it is an 
error if:


"Two or more modules in the configuration export the same package to a 
module that reads both. This includes the case where a module M 
containing package p reads another module that exports p to M."


Once you move beyond the command line and application module path then 
there is no issue if two modules have the same non-exported package.


-Alan

Re: Multiple versions of a non-exported dependency

[Neil Bartlett]

Hi Paul,

> On 31 Aug 2016, at 20:25, Paul Benedict  wrote:
> 
> Neil, but doesn't the prohibition of duplicate packages continue to rear
> its head?

I’m sorry I lost track of the context of this question! If you’re asking 
whether OSGi is prohibited from loading duplicate packages on Java 9, the 
answer is no.

In OSGi on Java 9 (or any earlier Java version) we use ClassLoaders to achieve 
isolation between modules. Therefore we explicitly support overlapping private 
packages, and even multiple modules with overlapping exported packages (NB the 
latter feature does require OSGi Release 4 or above, which was released in 
2004).

In contrast, Jigsaw/JPMS implements isolation using access control rather than 
ClassLoader visibility. All modules on the modulepath are loaded into the same 
ClassLoader, and a single ClassLoader can have at most one definition of each 
class. The implication is that two modules can conflict purely based on their 
private internals. If any tool attempts to construct valid module sets for use 
with the modulepath, it will not be sufficient for that tool to examine only 
the declared module metadata in module-info.class.

As Alex points out, you can work around this restriction by creating a Layer 
and mapping modules within that layer to separate ClassLoaders. If you do this 
then you will still need to manage the visibility of classes and delegation 
between ClassLoaders. In other words you will have started down the path of 
implementing your own ClassLoader-based module system comparable to where OSGi 
was in 1998.

Regards,
Neil


> 
> Cheers,
> Paul
> 
> On Wed, Aug 31, 2016 at 2:21 PM, cowwoc  wrote:
> 
>> Well, this is unfortunate. As I stated earlier, I fail to see how
>> depending on constant version numbers (not version ranges) fall under
>> the scope of "version selection". Was this case considered/discussed in
>> depth?
>> 
>> Not everyone is sold on version ranges (e.g. the vast majority of Maven
>> artifacts I've seen depend on constant versions) and I think this would
>> go a long way towards solving the original "classpath hell" problem.
>> 
>> Gili
>> 
>> On 2016-08-31 2:55 PM, Neil Bartlett [via jigsaw-dev] wrote:
>>> Gili,
>>> 
>>> As Alex points out: your use-case can be supported in Java 9 but only
>>> with the addition of custom ClassLoaders, or by using an existing
>>> ClassLoader-based module system such as OSGi.
>>> 
>>> The same is also true of Java 8, and Java 7, etc.
>>> 
>>> Regards,
>>> Neil
>>> 
>>> 
 On 31 Aug 2016, at 19:29, Alex Buckley <[hidden email]
>>> > wrote:
 
 On 8/31/2016 10:56 AM, cowwoc wrote:
> I recently became aware of the fact that the Jigsaw specification
>>> declared
> "version-selection" as a non-goal. While I understand how we ended
>>> up here,
> I am hoping that you were able to support the following (very common)
> use-case:
> 
> * Module "HelloWorld" depends on modules "Guava" and "JSoup".
> * Module "Guava" depends on module slf4j version 1 (requires but
>>> does not
> export it).
> * Module "JSoup" depends on module slf4j version 2 (requires but
>>> does not
> export it).
> * slf4j version 2 and is not backwards-compatible with version 1.
> 
> What happens at runtime? Will Jigsaw (out of the box, without
>>> 3rd-party
> tools like Maven or OSGI) be smart enough to provide different
>>> versions of
> slf4j to "Guava" and "JSoup"?
 
 (You mean Guava/JSoup requires slf4j version 1/2 and does not
>>> "re-export" it a.k.a. 'requires public'.)
 
 This use case isn't possible on JDK 8 for JARs on the classpath, and
>>> it's not supported on JDK 9 for modular JARs on the modulepath:
 
 - If you have two versions of a modular JAR slf4j.jar in different
>>> directories on the modulepath, then the first one to be found will
>>> dominate, and that's what will be resolved for both Guava and JSoup.
 
 - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the
>>> modulepath, and Guava requires slf4j_v1 and JSoup requires slf4j_v2,
>>> then launching 'java -m HelloWorld' will fail. The boot layer will
>>> refuse to map the "same" packages from different slf4j_v* modules to
>>> the application class loader.
 
 The use case _is_ supported on JDK 9 for modular JARs loaded into
>>> custom loaders of custom layers. That is, the Java Platform Module
>>> System is perfectly capable of supporting the use case -- please see
>>> any of my "Jigsaw: Under The Hood" presentations. The use case just
>>> isn't supported "out of the box" by the 'java' launcher for JARs on
>>> the modulepath.
 
 Alex
>>> 
>>> 
>>> 
>>> 
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>> http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-
>> of-a-non-exported-dependency-tp5713364p5713366.html
>>> 
>>> To unsubscribe from Mult