Re: Unnamed module and duplicate package

[Mandy Chung]

> On Mar 14, 2016, at 12:27 AM, David M. Lloyd  wrote:
> 
> On 3/12/16 9:57 AM, Alan Bateman wrote:
>> 
>> On 11/03/2016 15:30, David M. Lloyd wrote:
>>> 
>>> What are the limiting factors?  In my analysis the only problem that
>>> seemed close to insurmountable was the special natives that are used
>>> in the JDK but these only seem to be used from java.base.  Does it all
>>> boil down to getClassLoader()==null security checks on the Java side,
>>> or is there a JVM component that I haven't discovered?
>> I have no doubt that it would be a big effort.
>> 
>> One of the most difficult issues when de-privileging is identifying the
>> minimum permissions. It gets complicated in areas with callbacks where
>> intermediate frames reduce the effective permissions. For several of
>> these modules then it may be that they end up needing AllPermission so
>> the benefits of moving them out are significantly reduced.
>> 
>> Related is performance when running with a security manager. A long
>> standing optimization is that code in the boot loader has AllPermission.
>> 
>> At things stand then we can't move any modules that export java.* APIs.
>> If getPlatformClassLoader() and the related spec change to allow java.*
>> classes be loaded by the platform class loader and its ancestors goes in
>> then it removes this hurdle.
>> 
>> I'm sure there will be lots of other issues once you get into it. Some
>> of the modules (like java.management) are tightly coupled to the VM. On
>> getClassLoader() returning null then such uses would need to be
>> examined. I don't expect there are too many as we replaced a lot of them
>> in the JDK 8 time frame as part of JEP 162.
> 
> So really there are multiple parts to be able to move modules out of the 
> bootstrap class loader:
> 
> 1. Relax the spec so that other class loaders (preferably only 
> trusted/blessed class loaders) can define java.* classes
> 

This is only needed for modules defining java.* types.

> 2. Come up with a replacement for getClassLoader() == null checks (e.g. 
> getClassLoader() == null || getClassLoader().isPrivileged())
> 

We had attempted to clean up JDK code in JDK 8 and added 
jdk.internal.VM.isSystemDomainLoader(ClassLoader).

This is not that hard to identify.

Once it’s moved to be defined by the platform class loader, caller’s sensitive 
operations may require permission (e.g. methods that does security check based 
on the caller’s class loader).  The bootstrap class loader is also the root 
class loader which has access to all types defined by its child class loader.  
But that may not be true once it’s deprivileged.  We need to identify those 
caller-sensitive operations and wrap with doPrivileged if missing.

Also class resolution does a package-access check using the initiating class' 
protection domain.  This is extremely hard to diagnose.  The diagnosability of 
that area is really bugging me that really needs to be improved.

Not to mention when native code is involved but modularization is not cleaned.

 
> 3. Then go back and incrementally deprivilege as many modules as 
> possible/practical, as time permits
> 

There is no good existing tool to help analysis.  It heavily depends how well 
the existing test coverage is to run with security manager. Minimum set of 
permissions is the first step.  As Alan mentions, test, performance, 
compatibility and many other things to be thought through.

> However the benefits seem attractive: improved security (even if only one 
> module gets deprivileged), ability for core modules to depend on upgradable 
> modules (java.sql case).
> 

“core modules” - I assume you refer to the modules defined by the boot module.  
I don’t see why they need to depend on the upgradeable modules and don’t see 
any benefit.

> As far as allowing other class loaders to load java.* classes - could it not 
> just be a matter of setting a flag on ClassLoader which is only settable by a 
> non-public constructor or something like that?  

I don’t follow your suggestion on a flag.

java.* types currently is restricted to be defined by the bootstrap class 
loader.  The spec change is necessary to allow future deprivileging work to 
take place.


> The flag could be checked easily by Java or native code, and it doesn't tie 
> the JDK more tightly to specific hierarchical class loading arrangements.


What defining class loader of java.* type is unrelated to the class loader 
hierarchy.

Mandy

hg: jigsaw/jake/jdk: 2 new changesets

[mandy . chung]

Changeset: 01eba0a38afe
Author:mchung
Date:  2016-03-14 20:50 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01eba0a38afe

Update problem list with proper bug id

! test/ProblemList.jake.txt

Changeset: a2177e0d0f89
Author:mchung
Date:  2016-03-14 20:51 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a2177e0d0f89

Add @modules for test/sun/security/krb5/auto/HttpNegotiateServer.java

! test/sun/security/krb5/auto/HttpNegotiateServer.java

hg: jigsaw/jake/jdk: Un-problem list javax/management/mxbean/MXBeanLoadingTest1.java

[mandy . chung]

Changeset: 28cdd78d9e76
Author:mchung
Date:  2016-03-14 19:57 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/28cdd78d9e76

Un-problem list javax/management/mxbean/MXBeanLoadingTest1.java

! test/ProblemList.jake.txt

Re: Initial webrev with changes for JDK 9 jrtfs

[Sundararajan Athijegannathan]

Hi,

Thanks for the review. I've filed a bug to track the cleanups
suggested:  https://bugs.openjdk.java.net/browse/JDK-8151860

Quick comments:

1) jrt fs is read-only file system as you noted. Copying content into
jrt fs does not make sense. Eventually read-only file system exception
is thrown.
But, yes that cast can be avoided.

2) jrt-fs.jar is generated from jimage and jrt-fs sources and expected
to work on previous JDK (jdk 8 in this case). This is to support
cross-JDK reference to platform classes (from IDEs).
So, it is better to avoid internal JDK classes such as sun.nio.fs.Globs
in jrt-fs code.

Thanks,
-Sundar

On 3/15/2016 4:51 AM, Xueming Shen wrote:
>
> (5) JrtFileSystemProvider.copy(src, dst, ...options)
>
> The "dst/target" should not be cast to "AbstractJrtPath"? the jrtfs
> itself is
> a readonly, I'm not sure if we want to support the operation of copying
> a "file" output jrtfs. The copy/paste "copyToTarget" appears to be
> functional,
> if it's not a "AbstractJrtPath".
>
>
> On 03/14/2016 04:08 PM, Xueming Shen wrote:
>> (1) JrtFilePath: it does not seem to help performance to use the
>> byte[] as the
>>  internal storage.
>>
>> (2) AbstractJrtFilesystem.java
>>
>>   getPathMatcher:
>>
>>if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) {
>> expr = JrtUtils.toRegexPattern(input);
>> } else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) {
>>  expr = input;
>> } else {
>> throw new UnsupportedOperationException("Syntax '" +
>> syntax
>> + "' not recognized");
>>}
>>
>> (3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own copy?
>>
>> (4) JrtFilesystem.nodesToIterator()
>>
>> Stream has a "iterator() method. why need a collect() here?
>> different performance?
>> for example
>>
>>   private Iterator nodesToIterator(AbstractJrtPath dir,
>> List childNodes) {
>> return childNodes.stream()
>>  .map(child ->
>> (Path)dir.resolve(toJrtPath(child.getNameString()).getFileName()))
>>  .iterator();
>>   }
>>
>>
>> sherman
>>
>>
>

[9] Review request for FX Jigsaw changes

[Kevin Rushforth]

Please review the webrev for reviewing the jigsaw changes for FX.

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

http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt/
http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt-fxpackager/

I have separated out the in-progress changes to modules/fxpackager* 
(jdk.packager and jdk.packager.services modules) so they can be reviewed 
separately. However, they will be pushed along with the other changes as 
a single changeset.


These changes are planned to be integrated into FX 9 at the same time as 
the JDK changes are integrated (probably next week). They will be synced 
down to FX 9-dev shortly after that.


Please note the following:

* The required boot JDK to build FX after the Jigsaw integration will be 
JDK 9 build 109. We are not yet able to build with a Jigsaw-based JDK 9 
as the boot JDK yet, so we will be sticking at JDK 9 build 109 for a few 
weeks.


* gradle 2.11 is required to build using JDK 9

* In addition to building JavaFX as modules for use with a 
Jigsaw-capable JDK, we still build the "legacy sdk" using the existing 
pre-Jigsaw layout, including jfxrt.jar, etc. As such, most developers 
during the transition will hopefully not notice too much change.


* If you do want to run tests using the modules, you will need a 
Jigsaw-based JDK with javafx modules included, and point to that with a 
JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. If you 
actually want to build the JDK (which you will need to do if any module 
dependencies change), we will send out separate instructions. These will 
eventually make it onto the OpenJFX Wiki.


* The fxpackager modules are disabled by default. To enable them, you 
need to build a Jigsaw-based JDK *without* the jdk.pacakger* modules and 
point to that with a JDK9_HOME (likely to be changed to JIGSAW_HOME) env 
variable. Since most developers will not build in this mode, you need to 
set 'gradle -PBUILD_FXPACKAGER' to enable building the packager.


* I will refresh the webrev tomorrow afternoon, after making a couple of 
planned changes and reacting to any feedback, and again on Wednesday 
afternoon.


-- Kevin

hg: jigsaw/jake/langtools: ModulePathTest.java test fails after jmod --create is changed as subcommand

[mandy . chung]

Changeset: 062f84e9c5a0
Author:mchung
Date:  2016-03-14 17:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/062f84e9c5a0

ModulePathTest.java test fails after jmod --create is changed as subcommand

! test/tools/javac/modules/ModulePathTest.java

hg: jigsaw/jake/jdk: Test update per --plugin-module-path option rename

[mandy . chung]

Changeset: aaa5d9612312
Author:mchung
Date:  2016-03-14 16:59 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aaa5d9612312

Test update per --plugin-module-path option rename

! test/jdk/jigsaw/tools/lib/tests/JImageGenerator.java

hg: jigsaw/jake/jdk: Missing closing bracket in javadoc

[mandy . chung]

Changeset: db679f8c1122
Author:mchung
Date:  2016-03-14 15:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db679f8c1122

Missing closing bracket in javadoc

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

Re: Package, import and type declarations are allowed now in module-info.java by spec

[Alex Buckley]

The JLS doesn't know what the string "module-info.class" means or what a 
"JAR root" is. It only knows about Unicode input matching the 
CompilationUnit production. Nothing is mandated about the filesystem 
layout of files containing CompilationUnit productions that include a 
PackageDeclaration. For clarity, we could extend 7.6's compiler guidance 
to cover a file called module-info.java, but technically the guidance is 
already broad enough to allow a compiler to "do the right thing".


Alex

On 3/14/2016 9:08 AM, Paul Benedict wrote:

Alex, you wrote: "The JLS doesn't prevent javac from rejecting a package
declaration or an import declaration in a file called module-info.java."

It seems that a package declaration, in this context, should be
prohibited syntax because module-info.class is always in the JAR root
which has no package.

Cheers,
Paul

On Wed, Mar 9, 2016 at 4:02 PM, Alex Buckley > wrote:

The JLS doesn't prevent javac from rejecting a package declaration
or an import declaration in a file called module-info.java.

In fact, since a package declaration or import declaration must be
followed by a type declaration, and since a type declaration cannot
use a hyphen, javac is free to take the optional rule from JLS 7.6
-- filename must align with type declaration -- and develop it
further: rejecting a package declaration or import declaration in
module-info.java because the filename cannot possibly align with any
type declaration.

I can't speak to what a particular EA build of javac is doing with a
particular option. javac options are irrelevant to the JLS. If a
compiler accepts the Java language circa SE 9, then a module
declaration is a valid compilation unit. What's the name of the file
containing such a compilation unit? Anything the compiler likes.

Alex

On 3/9/2016 5:14 AM, Georgiy Rakov wrote:

Hi Alex,

if I understand correctly you mean about following assertions
from JLS 7.6:

 If and only if packages are stored in a file system (§7.2

),
 the host system may choose to enforce the restriction that
it is a
 compile-time error if a type is not found in a file under a
name
 composed of the type name plus an extension (such as |.java|or
 |.jav|) if either of the following is true:

   *

 The type is referred to by code in other compilation
units of
 the package in which the type is declared.

   *

 The type is declared |public|(and therefore is potentially
 accessible from code in other packages).

Literally these assertion doesn't make presented behavior
corresponding
to spec because the declared type is neither public nor being
referred
to from other sources being compiled.

Nevertheless following sources doesn't compile either despite
the fact
that no types are declared there at all.
Namely when only package is specified:

 mod\module-info.java:
 module mod {
  exports pkg;
 }

 mod\pkg\module-info.java:
 package pkg;

then compiling it by following command line with javac from [2]:

 javac -modulesourcepath . mod\module-info.java
mod\pkg\module-info.java

causes following output:

 mod\pkg\module-info.java:1: error: expected 'module
 package pkg;
 ^
 1 error

When only import statment is specified:

 mod\module-info.java:
 module mod {
  exports pkg;
 }

 mod\pkg\module-info.java:
 import java.util.List;

then compiling it by following command line with javac from [2]:

 javac -modulesourcepath . mod\module-info.java
mod\pkg\module-info.java

causes following output:

 mod\pkg\module-info.java:1: error: expected 'module'
 import java.util.List;
 ^
 1 error

Please see minimized test cases attached in tests23.zip. In order to
reproduce, please:

1. Unzip the attached archive to some dir on Windows machined, say
directory A;
2. Rename A\test2\test_bat to A\test2\test.bat and
A\test3\test_bat to
A\test3\test.bat;
3. Modify these two test.bat files by changing JDK_HOME variable to
point to your jigsaw JDK 9 installation directory;
4. Run test.bat files in turn.

BTW: javac behavior [2] currently differs depending on whether
sources
are compiled "in module" mode or not. By "module mode" I mean

hg: jigsaw/jake/langtools: remove temporary copy of old option

[jonathan . gibbons]

Changeset: afbcbbe35fe7
Author:jjg
Date:  2016-03-14 15:12 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/afbcbbe35fe7

remove temporary copy of old option

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java

hg: jigsaw/jake/langtools: remove obsolete dependence on java.lagging

[jonathan . gibbons]

Changeset: 46bf8a56f516
Author:jjg
Date:  2016-03-14 14:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/46bf8a56f516

remove obsolete dependence on java.lagging

! src/java.compiler/share/classes/module-info.java

hg: jigsaw/jake/jdk: Rename --plugins-modulepath to --plugin-module-path

[mandy . chung]

Changeset: e5bda5dfed8c
Author:mchung
Date:  2016-03-14 14:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5bda5dfed8c

Rename --plugins-modulepath to --plugin-module-path

! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties

hg: jigsaw/jake/langtools: improve javac -X output

[jonathan . gibbons]

Changeset: ed65135d4cd4
Author:jjg
Date:  2016-03-14 14:42 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ed65135d4cd4

improve javac -X output

! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties

hg: jigsaw/jake: Update jmod tool options and subcommands as per JEP 261

[chris . hegarty]

Changeset: aee43f8fb92a
Author:chegar
Date:  2016-03-14 21:32 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/aee43f8fb92a

Update jmod tool options and subcommands as per JEP 261

! make/CreateJmods.gmk

hg: jigsaw/jake/jdk: Update jmod tool options and subcommands as per JEP 261

[chris . hegarty]

Changeset: f57cdcac
Author:chegar
Date:  2016-03-14 21:19 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f57cdcac

Update jmod tool options and subcommands as per JEP 261

! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties
! test/jdk/jigsaw/launcher/basic/BasicTest.java
! test/jdk/jigsaw/module/ModuleReader/ModuleReaderTest.java
! test/jdk/jigsaw/tools/jlink/basic/BasicTest.java
! test/jdk/jigsaw/tools/jmod/JmodNegativeTest.java
! test/jdk/jigsaw/tools/jmod/JmodTest.java
! test/jdk/jigsaw/tools/lib/tests/JImageGenerator.java
! test/tools/jar/compat/CLICompatibility.java

Re: Support for multiple modules in one JAR-File

[Paul Benedict]

Stefan,

I am curious about your suggestion. Truthfully, I am not a fan of making
the JAR structure more complex; I think the 1:1 relationship between
physical artifact and module is easy and clean. However, I do wonder if
your suggestion can be met by the JMOD format? I think that format has as
one of its requirements the ability to bundle multiple resources together.
If that's the case, I see that as an easier avenue than adding complexity
to the JAR.

Cheers,
Paul

Re: Initial webrev with changes for JDK 9

[Mandy Chung]

> On Mar 11, 2016, at 1:39 AM, Alan Bateman  wrote:
> 
> 
> I've refreshed the webrevs here:
>   http://cr.openjdk.java.net/~alanb/8142968/2


I have reviewed the jmod tool and some comments:

299 private boolean printModuleDescriptor(InputStream in)

jmod -p option prints the output in different sections.
java -listmods: prints the module descriptor closer to 
module-info.java declaration.  Also jmod -p does not do any 
sorting and names are unordered.

It would be better for both options to use similar format.  I think
closer to how it is declared in module-info.java would be preferred.
The optional attributes will follow it - the existing format is fine.

It’d help if the package names and uses are printed in alphabetical order.

 584 } catch (ZipException x) {
 585 // Skip. Do nothing. No packages will be added

When ZipException is thrown?  Should it be handled in the same way as 
IOException?

 603 .filter(pkg -> pkg.length() > 0)   // module-info

I think jmod should detect if there is any unnamed package and output an error 
since unnamed package is not allowed in named module.  Currently any classes in 
unnamed package are include in the jmod file.

findPackages should filter module-info.class explicitly.

 396 Path tempTarget = target.resolveSibling(target.getFileName() + 
".tmp”);

When any error occurs, foo.mod.tmp is left behind.

jmods.properties - some unused messages.

err.cp.must.be.specified:--class-path must be specified
err.dir.not.empty=not empty: {0}
err.invalid.arg.for.option=invalid argument for option: {0}
err.option.after.class=option must be specified before classes: {0}

Mandy

hg: jigsaw/jake/jdk: M3 jdk8-dev review changes.

[james . laskey]

Changeset: 3067409f5ab9
Author:jlaskey
Date:  2016-03-14 16:53 -0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3067409f5ab9

M3 jdk8-dev review changes.

! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
! src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java
! src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java
! src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java
- src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java
- src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java
! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java
! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java
! src/java.base/share/classes/jdk/internal/jimage/ImageStream.java
! src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java
! src/java.base/share/classes/jdk/internal/jimage/ImageStringsReader.java
! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressIndexes.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java
! src/java.base/share/classes/jdk/internal/jimage/decompressor/Decompressor.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorFactory.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorRepository.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/SignatureParser.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressorFactory.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java
! 
src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressorFactory.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java

hg: jigsaw/jake/langtools: DocTrees.getElement shouldn't crash on an invalid package#member reference.

[jan . lahoda]

Changeset: 6cacf96c868b
Author:jlahoda
Date:  2016-03-14 20:58 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6cacf96c868b

DocTrees.getElement shouldn't crash on an invalid package#member reference.

! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! test/tools/javac/doctree/ReferenceTest.java

Re: Initial webrev with changes for JDK 9

[Xueming Shen]

jar.Main: comments

(1) InputstreamSupplier:
 since what we really need here is the byte[], maybe just go straightforward
 to use InputStream/Files.(path)readAllBytes() ?

(2) #273 don't the "moduleInfo" used for consistency check the same one as
 the used for updating at #244? can't be shared?

(3) if it was me I would simply have passed the "moduleInfoBytes" around as
 a byte[], we might not even need this "InputStreamSupplier" interface.

(4) printModuleDescriptor: for a "file" jar, it might be much faster to open the
 zip file with a ZipFile, then entry -> input stream. otherwise, the ZIS 
might
 be very slow if it's a big jar and the descriptor file is at the end of 
the file.

(5) hashDependences:
  "matcher" can be reused as
  Matcher m = dependenciesToHash.matcher("");
  for (...) {
  m.reset(...).find() ...
  }
  btw, what's the spec of the "mach" here? a "match()" or a "find()"? just 
check.

-sherman

hg: jigsaw/jake/jdk: Rename extension class loader to platform class loader

[mandy . chung]

Changeset: e97320e9c0ef
Author:mchung
Date:  2016-03-14 10:42 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e97320e9c0ef

Rename extension class loader to platform class loader

! make/gensrc/GensrcModuleLoaderMap.gmk
! make/src/classes/build/tools/module/GenModuleLoaderMap.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java
! src/java.base/share/classes/jdk/internal/loader/Loader.java
- src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.dat
! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java
+ src/java.base/share/classes/jdk/internal/vm/cds/resources/ModuleLoaderMap.dat
! src/java.base/share/classes/sun/reflect/Reflection.java
! test/com/sun/jdi/ModulesTest.java
! test/jdk/jigsaw/launcher/patch/PatchTest.java
! test/jdk/jigsaw/launcher/upgrademodulepath/src/test/jdk/test/Main.java

hg: jigsaw/jake/jdk: Fix a few typos in javadoc

[alan . bateman]

Changeset: 7081e2446f43
Author:alanb
Date:  2016-03-14 16:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7081e2446f43

Fix a few typos in javadoc

! src/java.base/share/classes/java/lang/module/Configuration.java
! src/java.base/share/classes/java/lang/module/ModuleFinder.java

Relationship between JDK modules and EE modules

[Paul Benedict]

In the future, is an application server meant to dynamically create a JDK
module from an EE module (EAR, WAR, EJB JAR)? I am not asking anyone to
define a specification; just curious how they are envisioned to interact.

Cheers,
Paul

Re: Unnamed module and duplicate package

[Alan Bateman]

On 14/03/2016 07:27, David M. Lloyd wrote:


So really there are multiple parts to be able to move modules out of 
the bootstrap class loader:


1. Relax the spec so that other class loaders (preferably only 
trusted/blessed class loaders) can define java.* classes
This is part of the getPlatformClassLoader() patch that Mandy sent mail 
about a few days ago. As part of this, defineClass is relaxed so that it 
allows java.* classes to be defined to the platform class loader or any 
of its ancestors





2. Come up with a replacement for getClassLoader() == null checks 
(e.g. getClassLoader() == null || getClassLoader().isPrivileged())
jdk.internal.VM.isSystemDomainLoader(ClassLoader) was introduced in JDK 
8 for this purpose.




3. Then go back and incrementally deprivilege as many modules as 
possible/practical, as time permits
Easier said that done as it can take a lot of effort to identify the 
minimum permissions, test, measure performance, assess compatibility and 
the many other things that need to be done.





However the benefits seem attractive: improved security (even if only 
one module gets deprivileged), ability for core modules to depend on 
upgradable modules (java.sql case).
Yes, on security although some modules need to granted more permissions 
that we'd like. So far, we've moved all of the EE/upgradeable modules:


java.activation
java.annotations.common
java.corba
java.transaction
java.xml.bind
java.xml.ws

and several service provider (jdk.*) modules have been moved too.

I don't see core modules depending on upgradeable modules as a benefit. 
My personal view is that we should vehemently resist any move in that 
direction. No issue with core modules using service providers of course.


-Alan

hg: jigsaw/jake/jdk: 3 new changesets

[alan . bateman]

Changeset: 3f8bb97a4b72
Author:alanb
Date:  2016-03-14 12:09 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f8bb97a4b72

Review comments

! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/java.base/share/classes/java/lang/module/ModuleInfo.java
! src/java.base/share/classes/java/lang/module/ModuleReader.java

Changeset: d7a8866e470b
Author:alanb
Date:  2016-03-14 12:10 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7a8866e470b

Fix copyright header

! test/jdk/jigsaw/module/VersionTest.java

Changeset: 7ce9360bfcb3
Author:alanb
Date:  2016-03-14 12:58 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ce9360bfcb3

API clean-up
-addmods ALL-MODULE-PATH

! make/src/classes/build/tools/jigsaw/GenGraphs.java
! make/src/classes/build/tools/jigsaw/ModuleSummary.java
! src/java.base/share/classes/java/lang/NamedPackage.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/module/Configuration.java
! src/java.base/share/classes/java/lang/module/ModuleFinder.java
! src/java.base/share/classes/java/lang/module/ResolutionException.java
+ src/java.base/share/classes/java/lang/module/ResolvedModule.java
! src/java.base/share/classes/java/lang/module/Resolver.java
! src/java.base/share/classes/java/lang/reflect/Layer.java
! src/java.base/share/classes/java/lang/reflect/Module.java
! src/java.base/share/classes/java/util/ServiceLoader.java
! src/java.base/share/classes/jdk/internal/loader/BootLoader.java
! src/java.base/share/classes/jdk/internal/loader/Loader.java
! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java
! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java
! src/java.base/share/classes/module-info.java
! src/java.base/share/classes/sun/launcher/resources/launcher.properties
! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java
! src/java.instrument/share/classes/java/lang/instrument/package.html
! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java
! test/java/lang/Class/forName/modules/TestLayer.java
! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java
! test/java/lang/Class/getResource/Main.java
! test/java/lang/ClassLoader/getResource/modules/Main.java
! test/java/lang/invoke/AccessControlTest.java
! test/jdk/jigsaw/module/AutomaticModulesTest.java
! test/jdk/jigsaw/module/ConfigurationTest.java
! test/jdk/jigsaw/reflect/Layer/BasicLayerTest.java
! test/jdk/jigsaw/reflect/Layer/LayerAndLoadersTest.java
! test/jdk/jigsaw/reflect/Module/BasicModuleTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java
! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java
! test/jdk/jigsaw/scenarios/automaticmodules/src/basictest/test/Main.java
! test/jdk/jigsaw/scenarios/container/src/container/container/Main.java
! test/jdk/jigsaw/util/ServiceLoader/ServicesTest.java

Re: jlink tool review (Re: Initial webrev with changes for JDK 9)

[Michael Haupt]

Hi again,

some certain list server doesn't like attachments. ;-)
Find it at http://cr.openjdk.java.net/~mhaupt/jigsaw/

Best,

Michael

> Am 14.03.2016 um 13:49 schrieb Michael Haupt :
> 
> Alan, all,
> 
> please find a patch with suggested changes to jlink in the attachment. The 
> patch also contains a file named review-comments.txt, which addresses several 
> topics throughout jlink. I've covered most code; only the jlink.internal 
> package is still missing. I've been able to compile jake with these 
> refactorings applied; I have not yet run all the jlink tests.
> 
> Unfortunately, I have to lay down the review work at this time; Sundar is 
> taking over (thanks!!). I'm available for clarification matters.
> 
> Best,
> 
> Michael


-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

jlink tool review (Re: Initial webrev with changes for JDK 9)

[Michael Haupt]

Alan, all,

please find a patch with suggested changes to jlink in the attachment. The 
patch also contains a file named review-comments.txt, which addresses several 
topics throughout jlink. I've covered most code; only the jlink.internal 
package is still missing. I've been able to compile jake with these 
refactorings applied; I have not yet run all the jlink tests.

Unfortunately, I have to lay down the review work at this time; Sundar is 
taking over (thanks!!). I'm available for clarification matters.

Best,

Michael



-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: Unnamed module and duplicate package

[David M. Lloyd]

On 3/12/16 9:57 AM, Alan Bateman wrote:


On 11/03/2016 15:30, David M. Lloyd wrote:


What are the limiting factors?  In my analysis the only problem that
seemed close to insurmountable was the special natives that are used
in the JDK but these only seem to be used from java.base.  Does it all
boil down to getClassLoader()==null security checks on the Java side,
or is there a JVM component that I haven't discovered?

I have no doubt that it would be a big effort.

One of the most difficult issues when de-privileging is identifying the
minimum permissions. It gets complicated in areas with callbacks where
intermediate frames reduce the effective permissions. For several of
these modules then it may be that they end up needing AllPermission so
the benefits of moving them out are significantly reduced.

Related is performance when running with a security manager. A long
standing optimization is that code in the boot loader has AllPermission.

At things stand then we can't move any modules that export java.* APIs.
If getPlatformClassLoader() and the related spec change to allow java.*
classes be loaded by the platform class loader and its ancestors goes in
then it removes this hurdle.

I'm sure there will be lots of other issues once you get into it. Some
of the modules (like java.management) are tightly coupled to the VM. On
getClassLoader() returning null then such uses would need to be
examined. I don't expect there are too many as we replaced a lot of them
in the JDK 8 time frame as part of JEP 162.


So really there are multiple parts to be able to move modules out of the 
bootstrap class loader:


1. Relax the spec so that other class loaders (preferably only 
trusted/blessed class loaders) can define java.* classes


2. Come up with a replacement for getClassLoader() == null checks (e.g. 
getClassLoader() == null || getClassLoader().isPrivileged())


3. Then go back and incrementally deprivilege as many modules as 
possible/practical, as time permits


However the benefits seem attractive: improved security (even if only 
one module gets deprivileged), ability for core modules to depend on 
upgradable modules (java.sql case).


As far as allowing other class loaders to load java.* classes - could it 
not just be a matter of setting a flag on ClassLoader which is only 
settable by a non-public constructor or something like that?  The flag 
could be checked easily by Java or native code, and it doesn't tie the 
JDK more tightly to specific hierarchical class loading arrangements.


--
- DML