Re: Revised proposal for #AutomaticModuleNames

[Brian Fox]

On Thu, May 4, 2017 at 1:39 PM,  wrote:

> Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
> Robert Scholte, for the extensive feedback.
>
>   http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2017-May/000687.html
>
> TL;DR: Keep automatic modules, bring back the module-name JAR-file
> manifest attribute, and strongly recommend reverse-DNS module names.
>
Comments?
>

I think this is a tremendous development that will allow a path towards
modularization and away from potential fragmentation of the Java ecosystem.
Thank you for continuing to consider our feedback after what I'm sure has
been a long slog to get this JSR over the finish line with a billion small
sheds painted many colors.


>
> - Mark
>

Re: Revised proposal for #AutomaticModuleNames

[mark . reinhold]

2017/5/4 14:21:38 -0700, Stephen Colebourne :
> On 4 May 2017 at 18:38, mark.reinh...@oracle.com wrote:
>> ...
>> 
>>  - Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose
>>value is used as the name of the automatic module defined by that JAR
>>file when it is placed on the module path, as previously suggested
> 
> This is a step forward wrt automatic modules.
> 
>>If a JAR file on the module path does not have such a
>>manifest attribute then its automatic-module name is computed using
>>the existing filename-based algorithm.
> 
> Which we all agree is almost guaranteed to be wrong.

... but it's better than any of the alternatives.

>>  - To increase awareness of when automatic modules are used, and of the
>>consequences of their use, suggest that Java language compilers issue
>>two new types of warnings, and implement these warnings in the RI:
> 
> Perhaps these should be reconsidered? If the module depends on an
> automatic module with a module name in the manifest, it can be
> considered reasonably stable. Whereas anything depending on a filename
> derived module name is unstable. That isn't being captured by the
> warnings.

Named automatic modules still have unstable APIs, so I don't think the
warnings need to be changed.  Maybe they could distinguish "unstable
name and API" vs. "unstable API only", but the opt-out warning for a
`requires transitive` directive that refers to an automatic module, even
if named, should be retained since that module's API is unstable.

>> In related threads on jigsaw-dev both Stephen Colebourne [e] and Robert
>> Scholte [f] suggest a new kind of explicit module, variously called
>> "partial" or "incomplete" or "soft", which can read all unnamed modules
>> so that dependencies that have not yet been modularized can be left on
>> the class path.  This is an attractive notion on the surface, and in fact
>> one that we partly implemented in the prototype code base over two years
>> ago, using the term "loose".  We didn't pursue it then, however, and I
>> don't think it's worth pursuing now, for two reasons:
>> 
>>  - If "partial" (or whatever) modules were to replace automatic modules
>>then application developers would have to wait until all of their
>>dependencies have been at least "partially" modularized before they
>>can even begin to experiment with modularizing their own code.
> 
> This seems demonstrably false.
> 
> module com.foo.application {
>   requires com.foo.lib;
> }
> partial module com.foo.lib {
>   exports com.foo.lib;
>   // TODO: requires guava
>   // TODO: requires joda-beans
> }
> modulepath = application
> classpath = guava, joda-beans
> 
> The application developer can write the module declarations above, and
> use them even though all the external dependencies are yet to be
> modularised. It seems clear to me that the application developer has
> modularised their application, even if not completely.

By "modularizing" in the above point I meant "completely modularizing",
but you're right: Application developers could start by writing their
own partial modules.  Is that really the best way, though, to encourage
everyone to approach modularization?

A useful aspect of the present design is that an explicit module is a
complete module.  If you've written a `module-info.java` file for your
component then you're done.  If explicit modules can be either partial
or complete then I worry that many people will partially modularize a
component but then never come back to completely modularize it.

I also think it's essential for a developer new to all of this to be
able to experiment immediately with both strong encapsulation
(`exports`) and reliable configuration (`requires`).  A story that says
"write a partial module now, come back and make it complete later on
after all of its dependencies have been (perhaps partially) modularized"
is a story in which you won't be able to write and debug your `requires`
directives until all of your dependencies have been (at least partially)
modularized.  That could be a pretty long story.

- Mark

Re: Revised proposal for #AutomaticModuleNames

[Stephen Colebourne]

On 4 May 2017 at 18:38,   wrote:
>   - Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose
> value is used as the name of the automatic module defined by that JAR
> file when it is placed on the module path, as previously suggested

This is a step forward wrt automatic modules.

> If a JAR file on the module path does not have such a
> manifest attribute then its automatic-module name is computed using
> the existing filename-based algorithm.

Which we all agree is almost guaranteed to be wrong.

>   - To increase awareness of when automatic modules are used, and of the
> consequences of their use, suggest that Java language compilers issue
> two new types of warnings, and implement these warnings in the RI:

Perhaps these should be reconsidered? If the module depends on an
automatic module with a module name in the manifest, it can be
considered reasonably stable. Whereas anything depending on a filename
derived module name is unstable. That isn't being captured by the
warnings.

> In related threads on jigsaw-dev both Stephen Colebourne [e] and Robert
> Scholte [f] suggest a new kind of explicit module, variously called
> "partial" or "incomplete" or "soft", which can read all unnamed modules
> so that dependencies that have not yet been modularized can be left on
> the class path.  This is an attractive notion on the surface, and in fact
> one that we partly implemented in the prototype code base over two years
> ago, using the term "loose".  We didn't pursue it then, however, and I
> don't think it's worth pursuing now, for two reasons:
>
>   - If "partial" (or whatever) modules were to replace automatic modules
> then application developers would have to wait until all of their
> dependencies have been at least "partially" modularized before they
> can even begin to experiment with modularizing their own code.

This seems demonstrably false.

module com.foo.application {
  requires com.foo.lib;
}
partial module com.foo.lib {
  exports com.foo.lib;
  // TODO: requires guava
  // TODO: requires joda-beans
}
modulepath = application
classpath = guava, joda-beans

The application developer can write the module declarations above, and
use them even though all the external dependencies are yet to be
modularised. It seems clear to me that the application developer has
modularised their application, even if not completely.

Given that this seems demonstrably false, I find the claim that
"application developers would have to wait" rather odd. This suggests
that something is perhaps not fully understood in the text above or
the partial proposal.

>   - We could solve that by keeping automatic modules and adding partial
> modules, but then we'd have a more complex module system and a more
> complex story to tell.

I agree with this. For me it either automatic or partial, not both.
And partial is a lot better in technical and community terms IMO as it
is a mechanism for reliable gradual migration. I still fail to see why
dumping the jars of the classpath on the modulepath and hoping it
works is a good strategy for migration - it seems like a bad short
cut.

Stephen


On 4 May 2017 at 18:39,   wrote:
> Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
> Robert Scholte, for the extensive feedback.
>
>   
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html
>
> TL;DR: Keep automatic modules, bring back the module-name JAR-file
> manifest attribute, and strongly recommend reverse-DNS module names.
>
> Comments?
>
> - Mark

Views on JSR 376 from the Eclipse JDT team

[Markus Keller]

Views on JSR 376 from the Eclipse JDT team
==

Here's a high-level feedback on things the Eclipse JDT team is missing in 
the Java Platform Module System spec (JSR 376).
(This message is based on an internal note from Markus Keller but 
basically reflects the position of the whole team)

The first problem is that's it's unclear what should be the spec.

http://openjdk.java.net/projects/jigsaw/spec/ says "This is the primary 
web page for JSR 376", but the JLS9 & JVMS9 drafts linked there are dated 
2017-02-22. Lots of discussions have been going on since then, and we 
can't be expected to pick out informal answers buried in mailing list 
posts.
=> Without a complete and up-to-date spec, the only reasonable vote on JSR 
376 is "no".

The other big thing is that the JLS draft specifies the syntax of the 
module-info.java file, but it is quite vague about the semantics of 
modules.

JLS9 12 "Execution" explains how class loading is supposed to work in the 
JVM, but it's unclear how modules and and their access restrictions should 
come into the picture here. Layers are not even mentioned anywhere. Before 
Java 9, classloading and discovery of .class files was only a run-time 
concern. During compilation, the assumption was that  all dependencies are 
available and accessible from a flat source-/classpath.
=> Since a Java compiler is now also supposed to check access restrictions 
imposed by module declarations, the JLS also needs to specify this in 
depth, or it at least needs to point to JavaSE-9 APIs that contain the 
necessary specifications. See e.g. Stephan Hermann's questions about the 
meaning of a qualified name.

Some examples:
- "The ordinary compilation units that are visible to M are the
observable ordinary compilation units associated with modules read by M. 
The host
system must use the Java Platform Module System to determine which modules
are read by M (§7.7.1)." 
=> Neither "read" nor "Java Platform Module System" are specified 
anywhere.

- "An implementation of the Java SE Platform must keep track of types 
within
packages by the combination of their enclosing module names and their 
binary
names (§13.1). Multiple ways of naming a type must be expanded to binary 
names
to make sure that such names are understood as referring to the same 
type."
=>What should happen if there are multiple types with the same binary name 
but different enclosing modules? Can they coexist or is this a compile 
error? JLS9 7.6 "Top Level Type Declarations" doesn't mention modules when 
it says: "It is a compile-time error if the name of a top level type 
appears as the name of any other top level class or interface type 
declared in the same package."

Such things are relevant if you want to write a compliant compiler.

E.g. JLS9 7.7 "Module Declarations" informally talks about "the 
modulepath" and "automatic modules", but neither of these concepts are 
explained any further. Automatic modules, unnamed modules, and their 
semantics must be specified in the JLS. The outdated 
http://openjdk.java.net/projects/jigsaw/spec/sotms/ has some more 
explanations, but since this is not part of the spec, it's irrelevant for 
a vote on JSR 376.

=> The JLS must either be self-contained or it must link to relevant other 
documents that are declared as equally dependable parts of the spec.

The grammar for the module-info.java with its "restricted keywords" is 
highly problematic, since the language it defines is not processable by 
established compiler technology. Hacks are possible, but they are costly 
and prevent established error recovery techniques from working.

These are only the concerns from a compiler and IDE implementer's 
perspective (i.e. answers whether we can implement something given the 
specs, not whether it's the right thing to do). We don't have a clear 
position on concerns voiced by implementers of existing Java modularity 
frameworks, but we're worried that the JPMS may not be suitable as a basis 
for those frameworks.

Regards,
The Eclipse JDT team

hg: jigsaw/jake/nashorn: 2 new changesets

[alan . bateman]

Changeset: c78163ad1a4e
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c78163ad1a4e

Added tag jdk-9+168 for changeset 0f81cde5a1f7

! .hgtags

Changeset: 61cbf87f8b49
Author:alanb
Date:  2017-05-04 19:06 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/61cbf87f8b49

Merge

! .hgtags

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: b2218d41edef
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b2218d41edef

Added tag jdk-9+168 for changeset 03a2cc9c8a1e

! .hgtags

Changeset: c8f59dfe1269
Author:alanb
Date:  2017-05-04 19:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c8f59dfe1269

Merge

! .hgtags

hg: jigsaw/jake/jdk: 2 new changesets

[alan . bateman]

Changeset: 8bfab0e73164
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bfab0e73164

Added tag jdk-9+168 for changeset e78da9db6299

! .hgtags

Changeset: 052d759c36a8
Author:alanb
Date:  2017-05-04 19:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/052d759c36a8

Merge

! .hgtags

hg: jigsaw/jake/hotspot: 2 new changesets

[alan . bateman]

Changeset: f36e864e66a7
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f36e864e66a7

Added tag jdk-9+168 for changeset fbb9c8026495

! .hgtags

Changeset: 1d55ec6b9bc7
Author:alanb
Date:  2017-05-04 19:06 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d55ec6b9bc7

Merge

! .hgtags

hg: jigsaw/jake/jaxp: 2 new changesets

[alan . bateman]

Changeset: df63b2d22ac6
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/df63b2d22ac6

Added tag jdk-9+168 for changeset 23a87f409371

! .hgtags

Changeset: a89495528083
Author:alanb
Date:  2017-05-04 19:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a89495528083

Merge

! .hgtags

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: e66ea56c8751
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e66ea56c8751

Added tag jdk-9+168 for changeset 2746716dcc5a

! .hgtags

Changeset: 5a7209da3317
Author:alanb
Date:  2017-05-04 19:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/5a7209da3317

Merge

! .hgtags

hg: jigsaw/jake: 2 new changesets

[alan . bateman]

Changeset: 8e1d0bed44e5
Author:lana
Date:  2017-05-04 16:38 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/8e1d0bed44e5

Added tag jdk-9+168 for changeset 143d4c87bc1e

! .hgtags

Changeset: c6f2f8eaafb2
Author:alanb
Date:  2017-05-04 19:01 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c6f2f8eaafb2

Merge

! .hgtags

Revised proposal for #AutomaticModuleNames

[mark . reinhold]

Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
Robert Scholte, for the extensive feedback.

  http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html

TL;DR: Keep automatic modules, bring back the module-name JAR-file
manifest attribute, and strongly recommend reverse-DNS module names.

Comments?

- Mark

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

[Kevin Rushforth]

This seems like something that could be useful, although at this point 
in the release we would more likely do it for JDK 10. I do note that 
including the class that made the illegal access is generally a good 
idea when that class is attempting the access on its own behalf. For 
frameworks such as JavaFX beans or FXML, we are making the request on 
behalf of an application, it wasn't as helpful to have the class itself 
be in the error message (which was Mandy's main point). So there are at 
least two cases to consider if we end up creating such a utility method.


Thanks.

-- Kevin


Gregg Wonderly wrote:

If there is not already such an exception, it would seem like a good idea to 
have an exception that formats such a message from constructor parameters 
providing the details so that it’s the same everywhere, and so that it can be 
changed in once place if needed.

Gregg

  

On May 3, 2017, at 9:48 AM, Kevin Rushforth  wrote:

OK, I'll create a more informative message. I think it will be more clear in the message 
to just say that it needs to "open" the package to javafx.base, since that 
would be the recommendation for a package that isn't already exported unconditionally. 
I'll send out a new webrev this morning with all feedback incorporated.

-- Kevin


Mandy Chung wrote:


On May 2, 2017, at 2:22 PM, Kevin Rushforth  wrote:

Here is the message:

IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base 
   


It would be better to emit a more informative message e.g. “javafx.base cannot 
access class com.foo (in module foo.app).  Either exports com.foo unqualifiedly 
or open com.foo to javafx.base”.  Also in MethodUtil::invoke
 61if (!module.isExported(packageName)) {
You can do this check only if module.isNamed.

 
  

It is roughly the same message that any similar illegal access would generate (e.g., we 
get similar error messages when FXML tries to call setAccessible for a field annotated 
with @FXML if the module is not "open" to javafx.fxml).

   


javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java
javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java
javafx.web/src/main/java/com/sun/webkit/MethodHelper.java
 45 public static Object invoke(Method m, Object obj, Object[] params)

To avoid 3 ModuleHelper classes, the invoke method can take
the callerModule argument to replace this line:   56 final Module 
thisModule = MethodHelper.class.getModule();
   
  

I'm fairly certain that won't work. Module::addOpens is caller sensitive and 
will only work when called from the module in question.

   


You are right.  Wont’t work.
 
  

javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java
 There are a few other public methods which I think JavaFX doesn’t
 need and can be removed.
   
  

Yes, I could do this to reduce the public footprint of the class. To minimize the diffs 
between the original and our copy, I might just comment out the "public". That 
would also make it easier to add them back in a future version (e.g., to eventually get 
rid of all dependency on sun.reflect.misc). Thoughts?
   


I will leave it up to you.
Mandy

 
  


  

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

[Gregg Wonderly]

If there is not already such an exception, it would seem like a good idea to 
have an exception that formats such a message from constructor parameters 
providing the details so that it’s the same everywhere, and so that it can be 
changed in once place if needed.

Gregg

> On May 3, 2017, at 9:48 AM, Kevin Rushforth  
> wrote:
> 
> OK, I'll create a more informative message. I think it will be more clear in 
> the message to just say that it needs to "open" the package to javafx.base, 
> since that would be the recommendation for a package that isn't already 
> exported unconditionally. I'll send out a new webrev this morning with all 
> feedback incorporated.
> 
> -- Kevin
> 
> 
> Mandy Chung wrote:
>>> On May 2, 2017, at 2:22 PM, Kevin Rushforth  
>>> wrote:
>>> 
>>> Here is the message:
>>> 
>>> IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot 
>>> access class com.foo (in module foo.app) because module foo.app does not 
>>> open com.foo to javafx.base 
>>>
>> 
>> It would be better to emit a more informative message e.g. “javafx.base 
>> cannot access class com.foo (in module foo.app).  Either exports com.foo 
>> unqualifiedly or open com.foo to javafx.base”.  Also in MethodUtil::invoke
>>  61if (!module.isExported(packageName)) {
>> You can do this check only if module.isNamed.
>> 
>>  
>>> It is roughly the same message that any similar illegal access would 
>>> generate (e.g., we get similar error messages when FXML tries to call 
>>> setAccessible for a field annotated with @FXML if the module is not "open" 
>>> to javafx.fxml).
>>> 
>>>
 javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java
 javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java
 javafx.web/src/main/java/com/sun/webkit/MethodHelper.java
  45 public static Object invoke(Method m, Object obj, Object[] params)
 
 To avoid 3 ModuleHelper classes, the invoke method can take
 the callerModule argument to replace this line:   56 final Module 
 thisModule = MethodHelper.class.getModule();

>>> I'm fairly certain that won't work. Module::addOpens is caller sensitive 
>>> and will only work when called from the module in question.
>>> 
>>>
>> 
>> You are right.  Wont’t work.
>>  
 javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java
  There are a few other public methods which I think JavaFX doesn’t
  need and can be removed.

>>> Yes, I could do this to reduce the public footprint of the class. To 
>>> minimize the diffs between the original and our copy, I might just comment 
>>> out the "public". That would also make it easier to add them back in a 
>>> future version (e.g., to eventually get rid of all dependency on 
>>> sun.reflect.misc). Thoughts?
>>>
>> 
>> I will leave it up to you.
>> Mandy
>> 
>>  

hg: jigsaw/jake: 11 new changesets

[alan . bateman]

Changeset: e1cd0e7075ae
Author:ksrini
Date:  2017-04-25 07:54 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e1cd0e7075ae

8178725: provide way to link to external documentation
Reviewed-by: dholmes, erikj, ihse, jjg

! make/Javadoc.gmk

Changeset: 4a25d35d9159
Author:ihse
Date:  2017-04-26 14:34 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4a25d35d9159

8178042: Allow custom taglets
Reviewed-by: erikj, mchung

! make/Javadoc.gmk

Changeset: 7f290cff26cd
Author:lana
Date:  2017-04-27 21:16 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7f290cff26cd

Merge


Changeset: 55b9ec67de79
Author:ihse
Date:  2017-04-28 10:46 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/55b9ec67de79

8179361: specify -javafx option for javadoc command
Reviewed-by: erikj

! make/Javadoc.gmk

Changeset: a09f8a1f40ef
Author:dnsimon
Date:  2017-04-27 23:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a09f8a1f40ef

8177845: Need a mechanism to load Graal
Reviewed-by: kvn, iveresov, mchung

! make/CompileJavaModules.gmk
! make/common/Modules.gmk

Changeset: 143d4c87bc1e
Author:erikj
Date:  2017-04-28 15:40 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/143d4c87bc1e

8179225: Update graphviz bundle script with up to date build instructions
Reviewed-by: tbell, ihse

! make/devkit/createGraphvizBundle.sh

Changeset: 481bd01358a9
Author:ihse
Date:  2017-05-03 08:46 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/481bd01358a9

8179453: Add a proper SetupProcessMarkdown
Reviewed-by: erikj

! common/doc/testing.md
! make/Javadoc.gmk
! make/UpdateBuildDocs.gmk
+ make/common/ProcessMarkdown.gmk

Changeset: 5288abbc445c
Author:erikj
Date:  2017-05-03 20:49 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/5288abbc445c

8179438: Incremental builds broken on Windows
Reviewed-by: tbell, ihse

! make/common/NativeCompilation.gmk

Changeset: 0b1d62e12105
Author:alanb
Date:  2017-05-04 07:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0b1d62e12105

8178380: Module system implementation refresh (5/2017)
Reviewed-by: alanb
Contributed-by: mandy.ch...@oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
! make/CreateJmods.gmk
! make/ReleaseFile.gmk

Changeset: 30db903fa442
Author:alanb
Date:  2017-05-04 09:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/30db903fa442

Merge

! common/autoconf/generated-configure.sh

Changeset: cdd7aa3eec8e
Author:alanb
Date:  2017-05-04 11:06 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/cdd7aa3eec8e

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
! make/CompileJavaModules.gmk
! make/CreateJmods.gmk
! make/Javadoc.gmk
! make/common/Modules.gmk
! make/common/NativeCompilation.gmk

hg: jigsaw/jake/hotspot: 6 new changesets

[alan . bateman]

Changeset: f1cca489e9c6
Author:kbarrett
Date:  2017-04-26 22:34 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f1cca489e9c6

8179084: HotSpot VM fails to start when AggressiveHeap is set
Summary: Don't set default ParallelGCThreads when processing AggressiveHeap
Reviewed-by: stefank, ehelin

! src/share/vm/runtime/arguments.cpp
+ test/gc/arguments/TestAggressiveHeap.java

Changeset: 537dbd601b34
Author:lana
Date:  2017-04-27 21:16 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/537dbd601b34

Merge


Changeset: fbb9c8026495
Author:dnsimon
Date:  2017-04-28 02:54 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fbb9c8026495

8177845: Need a mechanism to load Graal
Reviewed-by: kvn, iveresov, mchung

! .mx.jvmci/.pydevproject
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/EventProvider.java
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java
! 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java
+ 
src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/internal/ReflectionAccessJDK.java
! src/jdk.internal.vm.ci/share/classes/module-info.java
! src/jdk.internal.vm.compiler/.mx.graal/.pydevproject
! src/jdk.internal.vm.compiler/.mx.graal/suite.py
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.test/src/org/graalvm/compiler/api/test/Graal.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/ModuleAPI.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CheckGraalInvariants.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InterfaceMethodHandleTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/OptionsVerifierTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/StaticInterfaceFieldTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnbalancedMonitorsTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyBailoutUsageTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyDebugUsageTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyVirtualizableTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/VerifyMethodMetricsTest.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/tutorial/StaticAnalysis.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ConstantPoolSubstitutionsTests.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/TestIntrinsicCompiles.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompileTheWorld.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalCompilerFactory.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalJVMCIServiceLocator.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotInvocationPlugins.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/AESCryptSubstitutions.java
! 
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/CRC32Substitutions.java
! 

hg: jigsaw/jake/jdk: 34 new changesets

[alan . bateman]

Changeset: fa4bdd8f0eed
Author:chegar
Date:  2017-04-25 14:46 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa4bdd8f0eed

8158270: MulticastSendReceiveTests.java failed with "Expected message not 
received"
Reviewed-by: alanb

! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java

Changeset: 10eb52093bb8
Author:mchung
Date:  2017-04-25 09:09 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/10eb52093bb8

8179025: Exclude deployment modules from FieldSetAccessibleTest.java and 
VerifyJimage.java
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java
! test/jdk/modules/etc/JdkQualifiedExportTest.java
! test/tools/jimage/VerifyJimage.java

Changeset: fd5c621ad3b1
Author:ksrini
Date:  2017-04-25 07:52 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd5c621ad3b1

8178725: provide way to link to external documentation
Reviewed-by: erikj, ihse, jjg

+ make/src/classes/build/tools/taglet/ExtLink.java

Changeset: 1c6407c57773
Author:ihse
Date:  2017-04-26 14:35 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c6407c57773

8178042: Allow custom taglets
Reviewed-by: erikj, mchung

! make/CompileTools.gmk

Changeset: 7c04ab31b4d6
Author:naoto
Date:  2017-04-26 09:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c04ab31b4d6

8178412: Doc link updates for i18n
Reviewed-by: ksrini

! src/java.desktop/share/classes/java/awt/im/package-info.java
! src/java.desktop/share/classes/java/awt/im/spi/package-info.java
! src/java.desktop/share/classes/javax/swing/colorchooser/package-info.java
! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java

Changeset: bd0e423e5756
Author:jjg
Date:  2017-04-26 13:38 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bd0e423e5756

8179364: update "http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9bf7a7195e96

8179247: java/util/zip/TestExtraTime.java: add some instrumentation which might 
illuminate the failure of 2016-09-14
Summary: Add some instrumentation to help diagnosing 8166060
Reviewed-by: amlu, dfuchs, rriggs

! test/java/util/zip/TestExtraTime.java

Changeset: 6fe408bd34d2
Author:jjg
Date:  2017-04-26 16:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6fe408bd34d2

8179367: update use of align, valign attributes in java.base to use style 
attribute
Reviewed-by: martin, mchung

! src/java.base/share/classes/java/io/RandomAccessFile.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java
! src/java.base/share/classes/java/math/RoundingMode.java
! src/java.base/share/classes/java/nio/charset/Charset.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! src/java.base/share/classes/java/text/SimpleDateFormat.java
! src/java.base/share/classes/java/time/chrono/HijrahChronology.java
! src/java.base/share/classes/java/time/chrono/IsoEra.java
! src/java.base/share/classes/java/time/chrono/MinguoEra.java
! src/java.base/share/classes/java/time/chrono/ThaiBuddhistEra.java
! src/java.base/share/classes/java/time/format/DateTimeFormatter.java
! src/java.base/share/classes/java/util/Deque.java
! src/java.base/share/classes/java/util/Formatter.java
! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/java/util/Queue.java
! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/regex/Pattern.java

Changeset: 1fd0df22cdba
Author:chegar
Date:  2017-04-27 12:38 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1fd0df22cdba

8179392: Fix warnings in the httpclient javadoc
Reviewed-by: dfuchs

! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpRequest.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpResponse.java

Changeset: cb4af1e29ee8
Author:jjg
Date:  2017-04-27 09:47 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb4af1e29ee8

8179370: Replace use of ,  and  tags in java.base
Reviewed-by: darcy, alanb, mchung

! make/gensrc/GensrcCharsetCoder.gmk
! src/java.base/share/classes/java/io/DataInput.java
! src/java.base/share/classes/java/net/URLConnection.java
! src/java.base/share/classes/java/util/ServiceLoader.java
! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java

Changeset: dd173b9139be
Author:lana
Date:  2017-04-27 21:16 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dd173b9139be

Merge


Changeset: d9719d51c343
Author:weijun
Date:  2017-04-28 06:45 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d9719d51c343

8179369: 

hg: jigsaw/jake/nashorn: 3 new changesets

[alan . bateman]

Changeset: a3022cc65b17
Author:jjg
Date:  2017-04-26 10:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a3022cc65b17

8179304: Fix HTML 5 errors in jdk.scripting.nashorn and jdk.dynalink module
Reviewed-by: sundar, jlaskey, hannesw

! src/jdk.dynalink/share/classes/jdk/dynalink/StandardOperation.java
! 
src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingTypeConverterFactory.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/TreeVisitor.java

Changeset: 0f81cde5a1f7
Author:lana
Date:  2017-04-27 21:16 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0f81cde5a1f7

Merge


Changeset: 9d00d3d26242
Author:alanb
Date:  2017-05-04 11:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9d00d3d26242

Merge

Re: 8178380: Module system implementation refresh (5/2017 update)

[Alan Bateman]

On 04/05/2017 03:08, Mandy Chung wrote:




src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java

  148 if (System.getProperty("jdk.module.minimumBoot") != null) {
This property can be removed after read the value, if present.

It doesn't need to because VM terminates immediately.



I have fixed the above injake and also added a new test to verify
-—show-module-resolution option.


Okay, I'll check these out - thanks.