Re: Some suggested patches and improvements

[Michael Rasmussen]

On 12 May 2017 at 11:22, Alan Bateman  wrote:
> However for #3 then you've
> missed several important error cases, e.g. illegal package names, or the
> package is already in another module defined to the class loader.

These checks are already present in implAddPackage, so why duplicate
those checks in the wrapping method?

Speaking of, the package name check in implAddPackage seems
incomplete. addPackage("some...pkg") would pass the check, but it's
shouldn't be legal, as it contains empty segments.

/Michael

Re: Why not multiple modules of the same name in a class loader?

[David M. Lloyd]

On 05/12/2017 02:09 PM, David M. Lloyd wrote:

On 05/12/2017 01:46 PM, Remi Forax wrote:



On May 12, 2017 8:08:38 PM GMT+02:00, "David M. Lloyd" 
 wrote:

This has come up a couple times now and I'm not sure why the rule
exists: why not allow multiple modules with the same name in the same
class loader?


module names appear in the stack traces,  it will make life of people 
miserable if they have to open several artifacts to find the good one.


I agree; but, I wasn't looking for moral reasons, I was just curious 
about the technical constraint (if it even exists; maybe it does not!).



As far as I can tell, there is no way to locate a module by class
loader, and module namespaces are generally already well-governed by
their layer, so from an API perspective at least, it seems like this is

a harmless scenario (as long as there are no package conflicts,
obviously, but a container generally is able to manage this concern).

Preventing this does block one potential workaround for the lack of a
ModuleLayer.Controller.addPackage() method, which would be to
supplement
a module's content at run time by defining a new Layer that contains a
module of the same name as the original content within the same class
loader, where the container would then take care of such details as
mutual read/opening and cyclic access.

So that made me curious: is there some hotspot-internal dictionary that

I missed, which manages the set of modules within a class loader?


take a look to defineModule :)


I assume you mean Module.defineModule0 -> JVM_DefineModule -> 
Modules::define_module, which is where I looked.  It seemed to care 
about the class loader of the module, and about package names, but 
unless I'm just being blind to this (always a possibility), I don't see 
anyplace where it cares about what modules are defined to the class 
loader.  The closest thing I see is the bootstrap code which reads from 
the jimage, but none of that applies to user ModuleLayers.


In other words, I find no Map, or its C++ equivalent, at 
any level in a class loader that would be capable of such enforcement, 
let alone require it.


I guess I should do some more testing & tracing to see how this part 
works; maybe it's actually allowed!


Found it: there's a module table on ClassLoaderData that you get via its 
modules() method.



--
- DML

Re: An alternative to "restricted keywords"

[Remi Forax]

Hi Peter,

On May 12, 2017 6:08:58 PM GMT+02:00, Peter Levart  
wrote:
>Hi Remi,
>
>On 05/12/2017 08:17 AM, Remi Forax wrote:
>> [CC JPMS expert mailing list because, it's an important issue IMO]
>>
>> I've a counter proposition.
>>
>> I do not like your proposal because from the user point of view, '^'
>looks like a hack, it's not used anywhere else in the grammar.
>> I agree that restricted keywords are not properly specified in JLS.
>Reading your mail, i've discovered that what i was calling restricted
>keywords is not what javac implements :(
>> I agree that restricted keywords should be only enabled when parsing
>module-info.java
>> I agree that doing error recovery on the way the grammar for
>module-info is currently implemented in javac leads to less than ideal
>error messages.
>>
>> In my opinion, both
>> module m { requires transitive transitive; }
>> module m { requires transitive; }
>> should be rejected because what javac implements something more close
>to the javascript ASI rules than restricted keywords as currently
>specified by Alex.
>>
>> For me, a restricted keyword is a keyword which is activated if you
>are at a position in the grammar where it can be recognized and because
>it's a keyword, it tooks over an identifier.
>> by example for
>>module m {
>> if the next token is 'requires', it should be recognized as a keyword
>because you can parse a directive 'required ...' so there is a
>production that will starts with the 'required' keyword.
>>
>> so
>>module m { requires transitive; }
>> should be rejected because transitive should be recognized as a
>keyword after requires and the compiler should report a missing module
>name.
>>   
>> and
>>module m { requires transitive transitive; }
>> should be rejected because the grammar that parse the modifiers is
>defined as "a loop" so from the grammar point of view it's like
>>module m { requires Modifier Modifier; }
>> so the the front end of the compiler should report a missing module
>name and a later phase should report that there is twice the same
>modifier 'transitive'.
>>
>> I believe that with this definition of 'restricted keyword', compiler
>can recover error more easily and offers meaningful error message and
>the module-info part of the grammar is LR(1).
>
>This will make "requires", "uses", "provides", "with", "to", "static", 
>"transitive", "exports", etc  all illegal module names. Ok, no big 
>deal, because there are no module names yet (apart from JDK modules and
>
>those are named differently). But...

you should use reverse DNS naming for module name, so no problem. 

>
>What about:
>
>module m { exports transitive; }
>
>Here 'transitive' is an existing package name for example. Who 
>guarantees that there are no packages out there with names matching 
>restricted keywords? Current restriction for modules is that they can 
>not have an unnamed package. Do we want to restrict package names a 
>module can export too?

you should use reverse DNS naming for package so no problem :)

>
>Stephan's solution does not have this problem.
>
>Regards, Peter

I think those issues are not real problem. 

Rémi 

>
>>
>> regards,
>> Rémi
>>
>> - Mail original -
>>> De: "Stephan Herrmann" 
>>> À: jigsaw-dev@openjdk.java.net
>>> Envoyé: Mardi 9 Mai 2017 16:56:11
>>> Objet: An alternative to "restricted keywords"
>>> (1) I understand the need for avoiding that new module-related
>>> keywords conflict with existing code, where these words may be used
>>> as identifiers. Moreover, it must be possible for a module
>declaration
>>> to refer to packages or types thusly named.
>>>
>>> However,
>>>
>>> (2) The currently proposed "restricted keywords" are not
>appropriately
>>> specified in JLS.
>>>
>>> (3) The currently proposed "restricted keywords" pose difficulties
>to
>>> the implementation of all tools that need to parse a module
>declaration.
>>>
>>> (4) A simple alternative to "restricted keywords" exists, which has
>not
>>> received the attention it deserves.
>>>
>>> Details:
>>>
>>> (2) The current specification implicitly violates the assumption
>that
>>> parsing can be performed on the basis of a token stream produced by
>>> a scanner (aka lexer). From discussion on this list we learned that
>>> the following examples are intended to be syntactically legal:
>>> module m { requires transitive transitive; }
>>> module m { requires transitive; }
>>> (Please for the moment disregard heuristic solutions, while we are
>>>   investigating whether generally "restricted keywords" is a
>well-defined
>>>   concept, or not.)
>>> Of the three occurrences of "transitive", #1 is a keyword, the
>others
>>> are identifiers. At the point when the parser has consumed
>"requires"
>>> and now asks about classification of the word "transitive", the
>scanner
>>> cannot possible answer this classification. It can only answer for
>sure,
>>> after the *parser* has 

Re: An alternative to "restricted keywords"

[Peter Levart]

On 05/12/2017 06:08 PM, Peter Levart wrote:
For me, a restricted keyword is a keyword which is activated if you 
are at a position in the grammar where it can be recognized and 
because it's a keyword, it tooks over an identifier.

by example for
   module m {
if the next token is 'requires', it should be recognized as a keyword 
because you can parse a directive 'required ...' so there is a 
production that will starts with the 'required' keyword.


so
   module m { requires transitive; }
should be rejected because transitive should be recognized as a 
keyword after requires and the compiler should report a missing 
module name.

  and
   module m { requires transitive transitive; }
should be rejected because the grammar that parse the modifiers is 
defined as "a loop" so from the grammar point of view it's like

   module m { requires Modifier Modifier; }
so the the front end of the compiler should report a missing module 
name and a later phase should report that there is twice the same 
modifier 'transitive'.


I believe that with this definition of 'restricted keyword', compiler 
can recover error more easily and offers meaningful error message and 
the module-info part of the grammar is LR(1).


This will make "requires", "uses", "provides", "with", "to", "static", 
"transitive", "exports", etc  all illegal module names. Ok, no big 
deal, because there are no module names yet (apart from JDK modules 
and those are named differently). But...


What about:

module m { exports transitive; } 


...ok, I realized there's no problem in exports or opens as there are no 
exports/opens modifiers in the current syntax, so what follows 'exports' 
or 'opens' can always be interpreted as package name only. But what if 
some future extension of the language wants to define an exports or 
opens modifier? Or some new yet unexistent requires modifier?


Peter

Re: Why not multiple modules of the same name in a class loader?

[David M. Lloyd]

On 05/12/2017 01:46 PM, Remi Forax wrote:



On May 12, 2017 8:08:38 PM GMT+02:00, "David M. Lloyd"  
wrote:

This has come up a couple times now and I'm not sure why the rule
exists: why not allow multiple modules with the same name in the same
class loader?


module names appear in the stack traces,  it will make life of people miserable 
if they have to open several artifacts to find the good one.


I agree; but, I wasn't looking for moral reasons, I was just curious 
about the technical constraint (if it even exists; maybe it does not!).



As far as I can tell, there is no way to locate a module by class
loader, and module namespaces are generally already well-governed by
their layer, so from an API perspective at least, it seems like this is

a harmless scenario (as long as there are no package conflicts,
obviously, but a container generally is able to manage this concern).

Preventing this does block one potential workaround for the lack of a
ModuleLayer.Controller.addPackage() method, which would be to
supplement
a module's content at run time by defining a new Layer that contains a
module of the same name as the original content within the same class
loader, where the container would then take care of such details as
mutual read/opening and cyclic access.

So that made me curious: is there some hotspot-internal dictionary that

I missed, which manages the set of modules within a class loader?


take a look to defineModule :)


I assume you mean Module.defineModule0 -> JVM_DefineModule -> 
Modules::define_module, which is where I looked.  It seemed to care 
about the class loader of the module, and about package names, but 
unless I'm just being blind to this (always a possibility), I don't see 
anyplace where it cares about what modules are defined to the class 
loader.  The closest thing I see is the bootstrap code which reads from 
the jimage, but none of that applies to user ModuleLayers.


In other words, I find no Map, or its C++ equivalent, at 
any level in a class loader that would be capable of such enforcement, 
let alone require it.


I guess I should do some more testing & tracing to see how this part 
works; maybe it's actually allowed!


--
- DML

Re: Why not multiple modules of the same name in a class loader?

[Remi Forax]

On May 12, 2017 8:08:38 PM GMT+02:00, "David M. Lloyd"  
wrote:
>This has come up a couple times now and I'm not sure why the rule 
>exists: why not allow multiple modules with the same name in the same 
>class loader?

module names appear in the stack traces,  it will make life of people miserable 
if they have to open several artifacts to find the good one.

and if later the VM is able to isolate un-exported packages, it will be a real 
mess because at worst, you will have to follow all stack elements to find the 
class you want.


>
>As far as I can tell, there is no way to locate a module by class 
>loader, and module namespaces are generally already well-governed by 
>their layer, so from an API perspective at least, it seems like this is
>
>a harmless scenario (as long as there are no package conflicts, 
>obviously, but a container generally is able to manage this concern).
>
>Preventing this does block one potential workaround for the lack of a 
>ModuleLayer.Controller.addPackage() method, which would be to
>supplement 
>a module's content at run time by defining a new Layer that contains a 
>module of the same name as the original content within the same class 
>loader, where the container would then take care of such details as 
>mutual read/opening and cyclic access.
>
>So that made me curious: is there some hotspot-internal dictionary that
>
>I missed, which manages the set of modules within a class loader?

take a look to defineModule :)

Remi

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Some suggested patches and improvements

[David M. Lloyd]

On 05/12/2017 01:02 PM, David M. Lloyd wrote:

On 05/12/2017 08:31 AM, David M. Lloyd wrote:

On 05/12/2017 03:22 AM, Alan Bateman wrote:

On 12/05/2017 01:43, David M. Lloyd wrote:

I've proposed five patches to the jpms-spec-experts list [1..5] for 
discussion.  The patches are as follows:



[...]
3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to 
add packages to a module after it has been defined

[...]
However for #3 then you've missed several important error cases, e.g. 
illegal package names, or the package is already in another module 
defined to the class loader. There is impact in other areas too.


I wasn't worried about validating package names at first, because I 
figured that you could never define a class to the package anyway, but 
nevertheless I see the value in error detection (and avoiding piles of 
cruft inside the JVM regardless of whether it might trip any kind of 
internal assertion, which I acknowledge as a possibility as well), so 
I've pushed up a patch [1] to add package name validation.  This also 
detects the empty package name situation.


Detecting package conflict is somewhat more subtle; that's coming up next.

[1] 
https://github.com/dmlloyd/openjdk-modules/commit/a636c8891d6958d7b395a57d17c95699ee549500 


Here [2] is my first pass at detecting package conflict.  As an 
additional precaution, I forbid packages to be added to the bootstrap 
class loader in this way.


[2] 
https://github.com/dmlloyd/openjdk-modules/commit/f02719801ac41c6fd9b8c216f16c3f86b909e5fe



--
- DML

Why not multiple modules of the same name in a class loader?

[David M. Lloyd]

This has come up a couple times now and I'm not sure why the rule 
exists: why not allow multiple modules with the same name in the same 
class loader?


As far as I can tell, there is no way to locate a module by class 
loader, and module namespaces are generally already well-governed by 
their layer, so from an API perspective at least, it seems like this is 
a harmless scenario (as long as there are no package conflicts, 
obviously, but a container generally is able to manage this concern).


Preventing this does block one potential workaround for the lack of a 
ModuleLayer.Controller.addPackage() method, which would be to supplement 
a module's content at run time by defining a new Layer that contains a 
module of the same name as the original content within the same class 
loader, where the container would then take care of such details as 
mutual read/opening and cyclic access.


So that made me curious: is there some hotspot-internal dictionary that 
I missed, which manages the set of modules within a class loader?

--
- DML

Re: Some suggested patches and improvements

[David M. Lloyd]

On 05/12/2017 08:31 AM, David M. Lloyd wrote:

On 05/12/2017 03:22 AM, Alan Bateman wrote:

On 12/05/2017 01:43, David M. Lloyd wrote:

I've proposed five patches to the jpms-spec-experts list [1..5] for 
discussion.  The patches are as follows:



[...]
3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to 
add packages to a module after it has been defined

[...]
However for #3 then you've missed several important error cases, e.g. 
illegal package names, or the package is already in another module 
defined to the class loader. There is impact in other areas too.


I wasn't worried about validating package names at first, because I 
figured that you could never define a class to the package anyway, but 
nevertheless I see the value in error detection (and avoiding piles of 
cruft inside the JVM regardless of whether it might trip any kind of 
internal assertion, which I acknowledge as a possibility as well), so 
I've pushed up a patch [1] to add package name validation.  This also 
detects the empty package name situation.


Detecting package conflict is somewhat more subtle; that's coming up next.

[1] 
https://github.com/dmlloyd/openjdk-modules/commit/a636c8891d6958d7b395a57d17c95699ee549500


--
- DML

Re: Revised proposal for #AutomaticModuleNames

[Nicolai Parlog]

 Hi Stephen,

the shim only works partially. Qualified exports/opens for example
will not get past it. I did not yet investigate further to see whether
other problems occur.

However much we try module names will never be 100% stable and
providing an aliasing mechanism would solve this as well as other
problems (e.g. dropping in a replacement). But maybe that's something
for Java 9.1 or 10. ;)

 so long ... Nicolai



On 12.05.2017 17:23, Stephen Colebourne wrote:
> On 5 May 2017 at 15:41,   wrote:
>> I suspect what you really mean is "Never publish JARs that refer
>> to automatic modules that do not have `Automatic-Module-Name`
>> attributes". In general that's good advice.  It might even be
>> reasonable for managers of artifact repositories to insist upon
>> it, although I now understand that that could be problematic for
>> a repository as popular as Maven Central.
> 
> I think this is the tricky part. Lets review where we are.
> 
> Firstly, we now have super-package reverse-DNS names and MANIFEST 
> entries. Both of these are a very good thing.
> 
> Secondly, a module with a module-info can now depend on three
> things: - an explicit module with a module-info  (good) - an
> automatic module with MANIFEST entry  (good) - an automatic module
> with name implied from filename  (not good)
> 
> Thirdly, given the nature of Maven Central, it is not realistic to 
> prevent modules with dependencies on names implied from filenames 
> getting into Central.
> 
> My remaining concerns with automatic modules are primarily about
> this last point - we have to accept that there will be modules with
> "bad dependencies" in Maven Central. For example, the graph will
> end up with a dependency on "guava" that breaks when Guava is
> properly modularized and uses "com.google.common" as the module
> name. The result is a graph that does not resolve. While I and
> others will try and communicate this issue to the community, I
> would prefer that the issue simply could not occur.
> 
> 
> However, it has been pointed out to me off-list that there is a way
> to workaround the name change that I had not fully appreciated
> before.
> 
> Given this broken module graph state:
> 
> module com.foo.application { requires guava; } module
> com.google.common { }
> 
> it is possible to fix it by introducing an additional module as
> follows:
> 
> module guava { requires transient com.google.common; }
> 
> With this additional "renaming shim module" in the graph,
> everything now works again.
> 
> Given that there is a potential workaround, I am not as concerned
> as I previously was about this issue.
> 
> 
> Ideally, the creation of this "renaming shim module" should be part
> of the JDK (effectively it is a kind of alias, and the JDK is best
> placed to manage this). However, it should also be possible for
> tools like Maven to provide the shim dynamically when needed. It
> would even be possible to release such a shim module to Maven
> Central and depend on it in the usual way.
> 
> While this is still a workaround to an issue I wish didn't exist
> in the first place, it is a viable solution that I think allows
> automatic modules to proceed as is (given the JSR/release timeline
> pressure).
> 
> Stephen
> 

-- 

PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex=0xCA3BAD2E9CCCD509

Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund

Twitter:
https://twitter.com/nipafx

Re: Revised proposal for #AutomaticModuleNames

[Stephen Colebourne]

On 12 May 2017 at 18:29, Sander Mak  wrote:
>> module guava {
>>   requires transient com.google.common;
>> }
>>
>
> I suspect you mean 'transitive' here.

Yes :-)
Stephen

Re: Some suggested patches and improvements

[Jochen Theodorou]

On 12.05.2017 18:49, Michael Nascimento wrote:

#1-#3, IMHO, meet the needs of a niche who knows how to work around these
issues using other ways (although inconvenient).


I see me as someone needing this, and only having hints about how to 
make it work, that are based on annotation processors, which is no 
acceptable solution at all.


 bye Jochen

Re: Some suggested patches and improvements

[Michael Nascimento]

#1-#3, IMHO, meet the needs of a niche who knows how to work around these
issues using other ways (although inconvenient).

4 and 5 are solutions for problems any developer assembling a medium-large
application will definitely face and therefore are essential in my point of
view since it'd be unreasonable to expect the average developer to master
the black magic of low level module APIs or bytecode manipulation.

Regards,
Michael

On Thu, May 11, 2017 at 9:43 PM, David M. Lloyd 
wrote:

> I've proposed five patches to the jpms-spec-experts list [1..5] for
> discussion.  The patches are as follows:
>
> 1. Layer primitive: addExports() - mirrors the existing
> Module.addExports() method for ModuleLayer.Controllers
> 2. Layer primitive: addUses() - mirrors the existing Module.addUses()
> method for ModuleLayer.Controllers
> 3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to add
> packages to a module after it has been defined
> 4. Make run-time cycle checking optional
> 5. Add optional class loader isolation for modules on the module path
>
> Apart from #3, each of these patches is small and very low-risk, and
> address a clear problem.  In the case of #3, I believe that the risk is
> very low, but am also willing to discuss modifying the patch to move the
> method to a "jdk.unsupported" class or in other ways.
>
> I also am maintaining a mirror of the jigsaw/jake tree as a Git repository
> [6] which contains these patches where they can be viewed and fiddled with
> on a more interactive basis.
>
> It is my belief that these small, low-cost patches will go a very long way
> towards mitigating many of the problems identified and shared by Red Hat,
> by other EG members, by other EC members, and by the community.
>
> Please have a look and let me know if you have any feedback on any of
> these changes.
>
> [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-May/000705.html
> [2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-May/000707.html
> [3] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-May/000708.html
> [4] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-May/000711.html
> [5] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-May/000710.html
> [6] https://github.com/dmlloyd/openjdk-modules
>
> --
> - DML
>

Re: #AddExportsInManifest

[Paul Bakker]

Got it! It makes sense after this example. As a bit of feedback: I do think the 
naming of the properties is confusing. Because they are the same as the 
--add-opens/--add-exports flags, my assumption was they would work (exactly) 
the same.
Naming things is hard, and I don't have a better alternative, but maybe a more 
descriptive name could be considered for the properties? 

Thanks,

Paul


> On May 12, 2017, at 12:26 AM, Alan Bateman  wrote:
> 
> On 11/05/2017 21:25, Paul Bakker wrote:
> 
>> I'm a little confused by "...deployments work if they are dependent on JDK 
>> internal APIs". What does internal JDK usage have to do with 
>> opening/exporting your own packages? I would think this solves the problem 
>> that some other code (e.g. a library) requires access to application code?
>> Also, can you elaborate why this only applies to the unnamed module and 
>> can't do the same a the --add-exports/--add-opens flags?
>> 
> Hopefully the mail that Mandy references gives the context.
> 
> As an example, suppose an executable JAR that has code that is hacking into 
> sun.awt.X11 for some reason. To keep that code working then you could do:
> 
> java --add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -jar app.jar
> 
> but this isn't convenient for end-users that double click JAR files. The 
> equivalent for an executable JAR is to add "Add-Opens: java.desktop/sun.awt" 
> to its main manifest.
> 
> -Alan

Re: An alternative to "restricted keywords"

[Gregg Wonderly]

Or, would it make sense to make the module name require quotes around it?  The 
subtlety of this notation looking JSON like, and yet being something new, makes 
me wonder if it should not just be a JSON based structure

module : [
{
m : { 
requires : {
transitive :  [ “transitive” ]
}
}
},
{
n : {
requires : {
transitive : [ “m” ]
}
}
}
]

It would certainly provide a huge change in tooling possibilities.  But, it 
would add some additional requirements for a JSON parser.

Gregg

> On May 12, 2017, at 11:08 AM, Peter Levart  wrote:
> 
> Hi Remi,
> 
> On 05/12/2017 08:17 AM, Remi Forax wrote:
>> [CC JPMS expert mailing list because, it's an important issue IMO]
>> 
>> I've a counter proposition.
>> 
>> I do not like your proposal because from the user point of view, '^' looks 
>> like a hack, it's not used anywhere else in the grammar.
>> I agree that restricted keywords are not properly specified in JLS. Reading 
>> your mail, i've discovered that what i was calling restricted keywords is 
>> not what javac implements :(
>> I agree that restricted keywords should be only enabled when parsing 
>> module-info.java
>> I agree that doing error recovery on the way the grammar for module-info is 
>> currently implemented in javac leads to less than ideal error messages.
>> 
>> In my opinion, both
>>module m { requires transitive transitive; }
>>module m { requires transitive; }
>> should be rejected because what javac implements something more close to the 
>> javascript ASI rules than restricted keywords as currently specified by Alex.
>> 
>> For me, a restricted keyword is a keyword which is activated if you are at a 
>> position in the grammar where it can be recognized and because it's a 
>> keyword, it tooks over an identifier.
>> by example for
>>   module m {
>> if the next token is 'requires', it should be recognized as a keyword 
>> because you can parse a directive 'required ...' so there is a production 
>> that will starts with the 'required' keyword.
>> 
>> so
>>   module m { requires transitive; }
>> should be rejected because transitive should be recognized as a keyword 
>> after requires and the compiler should report a missing module name.
>>  and
>>   module m { requires transitive transitive; }
>> should be rejected because the grammar that parse the modifiers is defined 
>> as "a loop" so from the grammar point of view it's like
>>   module m { requires Modifier Modifier; }
>> so the the front end of the compiler should report a missing module name and 
>> a later phase should report that there is twice the same modifier 
>> 'transitive'.
>> 
>> I believe that with this definition of 'restricted keyword', compiler can 
>> recover error more easily and offers meaningful error message and the 
>> module-info part of the grammar is LR(1).
> 
> This will make "requires", "uses", "provides", "with", "to", "static", 
> "transitive", "exports", etc  all illegal module names. Ok, no big deal, 
> because there are no module names yet (apart from JDK modules and those are 
> named differently). But...
> 
> What about:
> 
> module m { exports transitive; }
> 
> Here 'transitive' is an existing package name for example. Who guarantees 
> that there are no packages out there with names matching restricted keywords? 
> Current restriction for modules is that they can not have an unnamed package. 
> Do we want to restrict package names a module can export too?
> 
> Stephan's solution does not have this problem.
> 
> Regards, Peter
> 
>> 
>> regards,
>> Rémi
>> 
>> - Mail original -
>>> De: "Stephan Herrmann" 
>>> À: jigsaw-dev@openjdk.java.net
>>> Envoyé: Mardi 9 Mai 2017 16:56:11
>>> Objet: An alternative to "restricted keywords"
>>> (1) I understand the need for avoiding that new module-related
>>> keywords conflict with existing code, where these words may be used
>>> as identifiers. Moreover, it must be possible for a module declaration
>>> to refer to packages or types thusly named.
>>> 
>>> However,
>>> 
>>> (2) The currently proposed "restricted keywords" are not appropriately
>>> specified in JLS.
>>> 
>>> (3) The currently proposed "restricted keywords" pose difficulties to
>>> the implementation of all tools that need to parse a module declaration.
>>> 
>>> (4) A simple alternative to "restricted keywords" exists, which has not
>>> received the attention it deserves.
>>> 
>>> Details:
>>> 
>>> (2) The current specification implicitly violates the assumption that
>>> parsing can be performed on the basis of a token stream produced by
>>> a scanner 

Re: An alternative to "restricted keywords"

[Peter Levart]

Hi Remi,

On 05/12/2017 08:17 AM, Remi Forax wrote:

[CC JPMS expert mailing list because, it's an important issue IMO]

I've a counter proposition.

I do not like your proposal because from the user point of view, '^' looks like 
a hack, it's not used anywhere else in the grammar.
I agree that restricted keywords are not properly specified in JLS. Reading 
your mail, i've discovered that what i was calling restricted keywords is not 
what javac implements :(
I agree that restricted keywords should be only enabled when parsing 
module-info.java
I agree that doing error recovery on the way the grammar for module-info is 
currently implemented in javac leads to less than ideal error messages.

In my opinion, both
module m { requires transitive transitive; }
module m { requires transitive; }
should be rejected because what javac implements something more close to the 
javascript ASI rules than restricted keywords as currently specified by Alex.

For me, a restricted keyword is a keyword which is activated if you are at a 
position in the grammar where it can be recognized and because it's a keyword, 
it tooks over an identifier.
by example for
   module m {
if the next token is 'requires', it should be recognized as a keyword because 
you can parse a directive 'required ...' so there is a production that will 
starts with the 'required' keyword.

so
   module m { requires transitive; }
should be rejected because transitive should be recognized as a keyword after 
requires and the compiler should report a missing module name.
  
and

   module m { requires transitive transitive; }
should be rejected because the grammar that parse the modifiers is defined as "a 
loop" so from the grammar point of view it's like
   module m { requires Modifier Modifier; }
so the the front end of the compiler should report a missing module name and a 
later phase should report that there is twice the same modifier 'transitive'.

I believe that with this definition of 'restricted keyword', compiler can 
recover error more easily and offers meaningful error message and the 
module-info part of the grammar is LR(1).


This will make "requires", "uses", "provides", "with", "to", "static", 
"transitive", "exports", etc  all illegal module names. Ok, no big 
deal, because there are no module names yet (apart from JDK modules and 
those are named differently). But...


What about:

module m { exports transitive; }

Here 'transitive' is an existing package name for example. Who 
guarantees that there are no packages out there with names matching 
restricted keywords? Current restriction for modules is that they can 
not have an unnamed package. Do we want to restrict package names a 
module can export too?


Stephan's solution does not have this problem.

Regards, Peter



regards,
Rémi

- Mail original -

De: "Stephan Herrmann" 
À: jigsaw-dev@openjdk.java.net
Envoyé: Mardi 9 Mai 2017 16:56:11
Objet: An alternative to "restricted keywords"
(1) I understand the need for avoiding that new module-related
keywords conflict with existing code, where these words may be used
as identifiers. Moreover, it must be possible for a module declaration
to refer to packages or types thusly named.

However,

(2) The currently proposed "restricted keywords" are not appropriately
specified in JLS.

(3) The currently proposed "restricted keywords" pose difficulties to
the implementation of all tools that need to parse a module declaration.

(4) A simple alternative to "restricted keywords" exists, which has not
received the attention it deserves.

Details:

(2) The current specification implicitly violates the assumption that
parsing can be performed on the basis of a token stream produced by
a scanner (aka lexer). From discussion on this list we learned that
the following examples are intended to be syntactically legal:
module m { requires transitive transitive; }
module m { requires transitive; }
(Please for the moment disregard heuristic solutions, while we are
  investigating whether generally "restricted keywords" is a well-defined
  concept, or not.)
Of the three occurrences of "transitive", #1 is a keyword, the others
are identifiers. At the point when the parser has consumed "requires"
and now asks about classification of the word "transitive", the scanner
cannot possible answer this classification. It can only answer for sure,
after the *parser* has accepted the full declaration. Put differently,
the parser must consume more tokens than have been classified by the
Scanner. Put differently, to faithfully parse arbitrary grammars using
a concept of "restricted keywords", scanners must provide speculative
answers, which may later need to be revised by backtracking or similar
exhaustive exploration of the space of possible interpretations.

The specification is totally silent about this fundamental change.


(3) "restricted keywords" pose three problems to tool implementations:

(3.a) Any known 

hg: jigsaw/jake/jdk: 3 new changesets

[alan . bateman]

Changeset: c59d273ab6db
Author:alanb
Date:  2017-05-12 14:37 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c59d273ab6db

Fix javadoc links

! src/java.base/share/classes/java/lang/ModuleLayer.java
! src/java.base/share/classes/jdk/internal/loader/Loader.java

Changeset: 5597f61c7b5a
Author:alanb
Date:  2017-05-12 16:24 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5597f61c7b5a

More SL cleanup and exception handling

! src/java.base/share/classes/java/util/ServiceLoader.java

Changeset: a6c4add6c917
Author:alanb
Date:  2017-05-12 16:26 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a6c4add6c917

Merge

- test/sample/TEST.properties
- test/sample/chatserver/ChatTest.java
- test/sample/mergesort/MergeSortTest.java

Re: Revised proposal for #AutomaticModuleNames

[Stephen Colebourne]

On 5 May 2017 at 15:41,   wrote:
> I suspect what you really mean is "Never publish JARs that refer to
> automatic modules that do not have `Automatic-Module-Name` attributes".
> In general that's good advice.  It might even be reasonable for managers
> of artifact repositories to insist upon it, although I now understand
> that that could be problematic for a repository as popular as Maven
> Central.

I think this is the tricky part. Lets review where we are.

Firstly, we now have super-package reverse-DNS names and MANIFEST
entries. Both of these are a very good thing.

Secondly, a module with a module-info can now depend on three things:
- an explicit module with a module-info  (good)
- an automatic module with MANIFEST entry  (good)
- an automatic module with name implied from filename  (not good)

Thirdly, given the nature of Maven Central, it is not realistic to
prevent modules with dependencies on names implied from filenames
getting into Central.

My remaining concerns with automatic modules are primarily about this
last point - we have to accept that there will be modules with "bad
dependencies" in Maven Central. For example, the graph will end up
with a dependency on "guava" that breaks when Guava is properly
modularized and uses "com.google.common" as the module name. The
result is a graph that does not resolve. While I and others will try
and communicate this issue to the community, I would prefer that the
issue simply could not occur.


However, it has been pointed out to me off-list that there is a way to
workaround the name change that I had not fully appreciated before.

Given this broken module graph state:

 module com.foo.application {
   requires guava;
 }
 module com.google.common {
 }

it is possible to fix it by introducing an additional module as follows:

 module guava {
   requires transient com.google.common;
 }

With this additional "renaming shim module" in the graph, everything
now works again.

Given that there is a potential workaround, I am not as concerned as I
previously was about this issue.


Ideally, the creation of this "renaming shim module" should be part of
the JDK (effectively it is a kind of alias, and the JDK is best placed
to manage this). However, it should also be possible for tools like
Maven to provide the shim dynamically when needed. It would even be
possible to release such a shim module to Maven Central and depend on
it in the usual way.

While this is still a workaround to an issue I wish didn't exist in
the first place, it is a viable solution that I think allows automatic
modules to proceed as is (given the JSR/release timeline pressure).

Stephen

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 72bb2cd3f013
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/72bb2cd3f013

Added tag jdk-9+169 for changeset b2218d41edef

! .hgtags

Changeset: b88b0bf4088f
Author:alanb
Date:  2017-05-12 14:21 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b88b0bf4088f

Merge

! .hgtags

hg: jigsaw/jake/jdk: 28 new changesets

[alan . bateman]

Changeset: 88379fba79d3
Author:amlu
Date:  2017-05-04 20:24 +0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88379fba79d3

8023897: Replace/update/rename executeAndCatch in various tests to assertThrows
Reviewed-by: dfuchs, prappo, psandoz, rriggs

! test/java/util/Arrays/ParallelPrefix.java
! test/java/util/Arrays/StreamAndSpliterator.java
! test/java/util/BitSet/stream/BitSetStreamTest.java
! test/java/util/Collections/EmptyNavigableMap.java
! test/java/util/Collections/EmptyNavigableSet.java
! test/java/util/Iterator/PrimitiveIteratorDefaults.java
! test/java/util/Map/Defaults.java
! test/java/util/Random/RandomTest.java
! test/java/util/Spliterator/SpliteratorCollisions.java
! test/java/util/Spliterator/SpliteratorFailFastTest.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java.base/java/util/SpliteratorTestHelper.java

Changeset: 1895211a6fe9
Author:lana
Date:  2017-05-04 17:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1895211a6fe9

Merge

- 
test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java

Changeset: adca794fc8e2
Author:lancea
Date:  2017-05-04 14:07 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/adca794fc8e2

8179634: Add JDBC 4.2 to bullet list in package.html
Reviewed-by: joehw

! src/java.sql/share/classes/java/sql/package.html

Changeset: 9c9b8a48cd4a
Author:shshahma
Date:  2017-04-27 00:08 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c9b8a48cd4a

8177721: Improve diagnostics in sun.management.Agent#startAgent()
Reviewed-by: dfuchs, dholmes, poonam

! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java

Changeset: d6b6ea1e292e
Author:poonam
Date:  2017-05-04 19:25 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6b6ea1e292e

Merge


Changeset: ae8ee67505d7
Author:mchung
Date:  2017-05-04 15:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae8ee67505d7

8179645: java.util.jar.Packer.newPacker and newUnpacker fails when running with 
security manager
Reviewed-by: alanb, ksrini

! src/java.base/share/classes/com/sun/java/util/jar/pack/PropMap.java
+ test/java/util/jar/Pack200/SecurityTest.java

Changeset: 58675e237ef1
Author:serb
Date:  2017-04-24 15:15 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/58675e237ef1

8178971: Uncommon formatting and typos in java.desktop module
Reviewed-by: prr, ssadetsky

! 
src/java.desktop/share/classes/java/awt/image/AbstractMultiResolutionImage.java
! src/java.desktop/share/classes/java/awt/package-info.java
! src/java.desktop/share/classes/javax/sound/midi/MetaMessage.java
! src/java.desktop/share/classes/javax/sound/midi/Sequence.java
! src/java.desktop/share/classes/javax/sound/midi/Sequencer.java
! src/java.desktop/share/classes/javax/sound/midi/ShortMessage.java
! src/java.desktop/share/classes/javax/sound/midi/SysexMessage.java
! src/java.desktop/share/classes/javax/sound/sampled/BooleanControl.java
! src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
! src/java.desktop/share/classes/javax/sound/sampled/LineEvent.java
! src/java.desktop/share/classes/javax/swing/JComponent.java
! src/java.desktop/share/classes/module-info.java

Changeset: 601479d462cb
Author:ssadetsky
Date:  2017-04-24 07:10 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/601479d462cb

8178905: Undecorated frame is not painted on OEL7(Gnome3).
Reviewed-by: prr, serb

! src/java.desktop/unix/classes/sun/awt/X11/XContentWindow.java

Changeset: 7cb3dc0422ea
Author:prr
Date:  2017-04-24 10:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7cb3dc0422ea

Merge

- src/java.management/share/classes/mgmt-overview.html
- src/java.security.jgss/share/classes/jgss-overview.html
- src/jdk.jdi/share/classes/jdi-overview.html
- src/jdk.security.auth/share/classes/jaas-overview.html
- test/java/time/TEST.properties
- test/java/util/BitSet/BitSetStreamTest.java

Changeset: caf8ee16cea8
Author:ssadetsky
Date:  2017-04-27 08:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/caf8ee16cea8

8179027: JComboBox too small under Windows LAF
Reviewed-by: prr, alexsch

! 
src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
+ test/javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java

Changeset: 120831a5da6f
Author:ssadetsky
Date:  2017-04-27 08:49 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/120831a5da6f

8140237: [TEST_BUG]Test javax/swing/plaf/nimbus/8041642/bug8041642.java fails 
for OEL 7
Reviewed-by: alexsch

! test/javax/swing/plaf/nimbus/8041642/bug8041642.java

Changeset: 825903c4e875
Author:prr
Date:  2017-04-27 14:07 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/825903c4e875

8179365: JAWT (AWT Native Interface) 

hg: jigsaw/jake/jaxws: 3 new changesets

[alan . bateman]

Changeset: 912cf69806d5
Author:lancea
Date:  2017-05-05 13:32 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/912cf69806d5

8179566: Add additional jaxws messages to be translated
Reviewed-by: alanb, mchung

+ 
src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties

Changeset: e75d3abe579a
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e75d3abe579a

Added tag jdk-9+169 for changeset 912cf69806d5

! .hgtags

Changeset: f5ae1e9f7870
Author:alanb
Date:  2017-05-12 14:21 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/f5ae1e9f7870

Merge

! .hgtags

hg: jigsaw/jake/jaxp: 5 new changesets

[alan . bateman]

Changeset: 60abb1d1cd1d
Author:ihse
Date:  2017-05-09 12:54 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/60abb1d1cd1d

8179889: Fix typographic errors in copyright headers
Reviewed-by: erikj, dholmes

! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
! 
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java
! 
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java
! 
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java

Changeset: f9abe02cceda
Author:joehw
Date:  2017-05-09 10:34 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f9abe02cceda

8150256: removing xerces-related dead code
Reviewed-by: lancea

- 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerElementHandler.java
- 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerFramework.java
- 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerSchema.java

Changeset: 5d9d2a65fb26
Author:joehw
Date:  2017-05-09 11:46 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5d9d2a65fb26

8179863: Missing copyrights in some jaxp files
Reviewed-by: lancea

! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathParser.java
! 
src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java

Changeset: f263aa7f60c3
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f263aa7f60c3

Added tag jdk-9+169 for changeset 5d9d2a65fb26

! .hgtags

Changeset: a3bdddfa511f
Author:alanb
Date:  2017-05-12 14:21 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a3bdddfa511f

Merge

! .hgtags
- 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerElementHandler.java
- 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerFramework.java
- 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerSchema.java

hg: jigsaw/jake/langtools: 5 new changesets

[alan . bateman]

Changeset: 5daed0e904ac
Author:lana
Date:  2017-05-04 17:55 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5daed0e904ac

Merge


Changeset: 1faee09b8da1
Author:jlahoda
Date:  2017-05-09 12:22 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1faee09b8da1

8179531: JShell: fails to provide bytecode for dynamically created lambdas
Summary: Adding support for getResource(s) to the JShell's ClassLoader
Reviewed-by: psandoz, rfield

! src/jdk.jshell/share/classes/jdk/jshell/execution/DefaultLoaderDelegate.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiExecutionControl.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/LoaderDelegate.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java
+ test/jdk/jshell/GetResourceTest.java

Changeset: 0e522ff8b9f5
Author:ihse
Date:  2017-05-09 12:55 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0e522ff8b9f5

8179889: Fix typographic errors in copyright headers
Reviewed-by: erikj, dholmes

! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java
! test/jdk/javadoc/doclet/testStylesheet/pkg/A.java
! test/jdk/javadoc/tool/treeapi/overview.html
! test/jdk/jshell/WrapperTest.java
! test/tools/javac/classreader/8171132/BadConstantValue.java
! test/tools/javac/modules/PoorChoiceForModuleNameTest.java
! test/tools/javadoc/sampleapi/res/fx.xml
! test/tools/javadoc/sampleapi/res/simple.xml
! test/tools/javadoc/sampleapi/res/tiny.xml

Changeset: bc191bf0aa56
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bc191bf0aa56

Added tag jdk-9+169 for changeset 0e522ff8b9f5

! .hgtags

Changeset: 69ae34a97515
Author:alanb
Date:  2017-05-12 14:20 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/69ae34a97515

Merge

! .hgtags

hg: jigsaw/jake/hotspot: 5 new changesets

[alan . bateman]

Changeset: 70548873832d
Author:lana
Date:  2017-05-04 17:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/70548873832d

Merge


Changeset: d7da8c2b8b6c
Author:roland
Date:  2017-04-25 09:37 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d7da8c2b8b6c

8179070: nashorn+octane's box2d causes c2 to crash with "Bad graph detected in 
compute_lca_of_uses"
Summary: ciTypeFlow speculates field is null but parsing uses non null constant 
because of concurrent class initialization
Reviewed-by: thartmann

! src/share/vm/opto/parse3.cpp

Changeset: 16d692be099c
Author:ihse
Date:  2017-05-09 12:53 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/16d692be099c

8179889: Fix typographic errors in copyright headers
Reviewed-by: erikj, dholmes

! src/cpu/aarch64/vm/assembler_aarch64.cpp
! 
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java
! test/gc/class_unloading/TestClassUnloadingDisabled.java
! test/native/logging/test_logTagSetDescriptions.cpp
! test/native/memory/test_metachunk.cpp
! test/runtime/CommandLine/PermGenFlagsTest.java
! test/runtime/logging/ThreadLoggingTest.java
! test/runtime/logging/p2/B.jcod
! test/testlibrary/ctw/Makefile

Changeset: 910e24afc502
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/910e24afc502

Added tag jdk-9+169 for changeset 16d692be099c

! .hgtags

Changeset: 608adb9f402d
Author:alanb
Date:  2017-05-12 14:20 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/608adb9f402d

Merge

! .hgtags
! 
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java

hg: jigsaw/jake/nashorn: 3 new changesets

[alan . bateman]

Changeset: 131e25008015
Author:ihse
Date:  2017-05-09 12:54 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/131e25008015

8179889: Fix typographic errors in copyright headers
Reviewed-by: erikj, dholmes

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/TypeMap.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SpillProperty.java
! test/script/basic/JDK-8150218.js
! test/script/basic/JDK-8170594.js
! test/script/basic/JDK-8171849.js
! test/script/basic/es6/JDK-8168373.js

Changeset: 597d3dc02579
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/597d3dc02579

Added tag jdk-9+169 for changeset 131e25008015

! .hgtags

Changeset: 85cc76af3c6c
Author:alanb
Date:  2017-05-12 14:22 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/85cc76af3c6c

Merge

! .hgtags

hg: jigsaw/jake: 7 new changesets

[alan . bateman]

Changeset: 25a364291f63
Author:lana
Date:  2017-05-04 17:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/25a364291f63

Merge


Changeset: 7931344eeb84
Author:ihse
Date:  2017-05-05 13:56 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7931344eeb84

8179557: Update generated Javadoc footer documentation link
Reviewed-by: erikj

! make/Javadoc.gmk

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

8179658: SetupProcessMarkdown creates long file names
Reviewed-by: tbell, erikj

! make/Javadoc.gmk

Changeset: 65694748f53c
Author:ihse
Date:  2017-05-08 14:02 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/65694748f53c

8140268: Generate link to specification license for JavaDoc API documentation
Reviewed-by: erikj

! make/Javadoc.gmk

Changeset: b25838a28195
Author:ihse
Date:  2017-05-09 14:31 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/b25838a28195

8179879: Clarify install.sh
Reviewed-by: erikj

! common/autoconf/build-aux/install.sh

Changeset: a0ce1616b7f1
Author:lana
Date:  2017-05-11 16:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a0ce1616b7f1

Added tag jdk-9+169 for changeset b25838a28195

! .hgtags

Changeset: f1f818e27056
Author:alanb
Date:  2017-05-12 14:19 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f1f818e27056

Merge

! .hgtags
! make/Javadoc.gmk

Re: Some suggested patches and improvements

[Stephen Colebourne]

On 12 May 2017 at 01:43, David M. Lloyd  wrote:
> 1. Layer primitive: addExports() - mirrors the existing Module.addExports()
> method for ModuleLayer.Controllers
> 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method
> for ModuleLayer.Controllers
> 3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to add
> packages to a module after it has been defined

Are these a good idea? I don't know. What I do know is that the use
cases for them seem to be focussed on low-level coders and framework
writers, which is a very small subset of all Java developers, and a
group who can work around difficulties.

> 4. Make run-time cycle checking optional

My opinion is that run-time cycles are inevitable. The proposed
solutions (refactoring to API vs Impl) is not particularly good in an
open source context. I'm also concerned that "requires static"
(optional dependencies) also naturally leads to cycles

But the question at this point is whether it is worth the effort to
try and live without cycles for this release - after all, no-one wants
cycles in their design. Since there is a workaround, via the
low-level module/layer code, it feels like we should be willing to
take the punt and try to live without cycles in 9 keeping it under
review to add in 10.

> 5. Add optional class loader isolation for modules on the module path

Again, my opinion is that the isolation of modules is insufficient in
Jigsaw and that hidden packages will sometimes be very messy. However,
the only tool available to solve this appears to be classloaders, and
they have plenty of flaws themselves. While opt-in isolation appears
tempting, I'd prefer to wait and see a better solution in a later
version. Maybe the answer is to deprecated class loaders and come up
with something better!


Given where we are, I think my preference is to see a JDK 9 release
soon rather than end the JSR over these issues.

Stephen

Re: Some suggested patches and improvements

[David M. Lloyd]

On 05/12/2017 03:22 AM, Alan Bateman wrote:

On 12/05/2017 01:43, David M. Lloyd wrote:

I've proposed five patches to the jpms-spec-experts list [1..5] for 
discussion.  The patches are as follows:


1. Layer primitive: addExports() - mirrors the existing 
Module.addExports() method for ModuleLayer.Controllers
2. Layer primitive: addUses() - mirrors the existing Module.addUses() 
method for ModuleLayer.Controllers
3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to 
add packages to a module after it has been defined

4. Make run-time cycle checking optional
5. Add optional class loader isolation for modules on the module path

>
#1-#3 are a subset of issue #LayerPrimitives in the JSR. I don't wish to 
comment on whether these make sense or not.


No problem, I'm just looking for technical feedback here.

However for #3 then you've 
missed several important error cases, e.g. illegal package names, or the 
package is already in another module defined to the class loader. There 
is impact in other areas too.


I can look into these two items; can you expand on the other impacts?

#4 seems to be working around the outcome of issue #CyclicDependences in 
the JSR. I also don't wish to comment on that except to say that 
introducing system properties to skip specified checks is highly 
problematic from a conformance perspective.


Can you explain what you mean by that?  I'm more than happy to convert 
these into -X type arguments to the runtime (or, of course, to simply 
make this the standard behavior), but I thought this would be a simpler 
and safer approach (at least for a first pass).


The only other place where I found run time cycles to be relevant is 
jlink and a couple of other tools, which I am in the process of 
developing a similar patch for.


There is a lot more to #5, something that will become clear when you 
work through all the scenarios. The JSR and spec part are minor though 
but I'd prefer to hold off until there is more discussion on this topic 
in the JSR.


I'd rather not hold off as the JSR essentially only has a couple of 
weeks left to live if there is not a revised PR.  Could you please 
explain what you mean?  Are you referring to jlink, jaotc, or something 
else?


--
- DML

Re: Some suggested patches and improvements

[Alan Bateman]

On 12/05/2017 01:43, David M. Lloyd wrote:

I've proposed five patches to the jpms-spec-experts list [1..5] for 
discussion.  The patches are as follows:


1. Layer primitive: addExports() - mirrors the existing 
Module.addExports() method for ModuleLayer.Controllers
2. Layer primitive: addUses() - mirrors the existing Module.addUses() 
method for ModuleLayer.Controllers
3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to 
add packages to a module after it has been defined

4. Make run-time cycle checking optional
5. Add optional class loader isolation for modules on the module path
#1-#3 are a subset of issue #LayerPrimitives in the JSR. I don't wish to 
comment on whether these make sense or not. However for #3 then you've 
missed several important error cases, e.g. illegal package names, or the 
package is already in another module defined to the class loader. There 
is impact in other areas too.


#4 seems to be working around the outcome of issue #CyclicDependences in 
the JSR. I also don't wish to comment on that except to say that 
introducing system properties to skip specified checks is highly 
problematic from a conformance perspective.


There is a lot more to #5, something that will become clear when you 
work through all the scenarios. The JSR and spec part are minor though 
but I'd prefer to hold off until there is more discussion on this topic 
in the JSR.


-Alan

Re: #AddExportsInManifest

[Alan Bateman]

On 11/05/2017 21:25, Paul Bakker wrote:


I'm a little confused by "...deployments work if they are dependent on JDK internal 
APIs". What does internal JDK usage have to do with opening/exporting your own 
packages? I would think this solves the problem that some other code (e.g. a library) 
requires access to application code?
Also, can you elaborate why this only applies to the unnamed module and can't 
do the same a the --add-exports/--add-opens flags?


Hopefully the mail that Mandy references gives the context.

As an example, suppose an executable JAR that has code that is hacking 
into sun.awt.X11 for some reason. To keep that code working then you 
could do:


java --add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -jar app.jar

but this isn't convenient for end-users that double click JAR files. The 
equivalent for an executable JAR is to add "Add-Opens: 
java.desktop/sun.awt" to its main manifest.


-Alan

Re: SecurityManager.checkPackageAccess for qualified exports

[Alan Bateman]

On 12/05/2017 08:16, Langer, Christoph wrote:


Hi all,

while playing with the security manager (using -Djava.security.manager) in Java 
9 and testing platform modules that we have added specifically in our build, I 
came across the following thing:

As we are using some stuff from jdk.internal, I get the AccessControlException: "exception access denied 
("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.misc")" in several places, even if my 
code runs priviledged. I figured that I need to grant permission "permission java.lang.RuntimePermission 
"accessClassInPackage.jdk.internal.misc"" to my module. I was looking around where this restriction comes from and 
learned the following in the documentation of SecurityManager.checkPackageAccess:


Implementation Note:
This implementation also restricts all non-exported packages of modules loaded by the platform 
class 
loader
 or its ancestors. A "non-exported package" refers to a package that is not exported 
to all modules. Specifically, it refers to a package that either is not exported at all by its 
containing module or is exported in a qualified fashion by its containing module.

Reading this, I'm wondering whether the implementation should implicitly grant 
package access for modules that a package in question was exported to in a 
qualified fashion? Now one ends up having to additionally add specific 
permissions which can easily be forgot.

Any comments? Shouldn't that be improved?

I recall there was some discussion on this topic already - can you bring 
this to security-dev where the changes in this area were discussed/reviewed?


-Alan

SecurityManager.checkPackageAccess for qualified exports

[Langer, Christoph]

Hi all,

while playing with the security manager (using -Djava.security.manager) in Java 
9 and testing platform modules that we have added specifically in our build, I 
came across the following thing:

As we are using some stuff from jdk.internal, I get the AccessControlException: 
"exception access denied ("java.lang.RuntimePermission" 
"accessClassInPackage.jdk.internal.misc")" in several places, even if my code 
runs priviledged. I figured that I need to grant permission "permission 
java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc"" to my 
module. I was looking around where this restriction comes from and learned the 
following in the documentation of SecurityManager.checkPackageAccess:


Implementation Note:
This implementation also restricts all non-exported packages of modules loaded 
by the platform class 
loader
 or its ancestors. A "non-exported package" refers to a package that is not 
exported to all modules. Specifically, it refers to a package that either is 
not exported at all by its containing module or is exported in a qualified 
fashion by its containing module.

Reading this, I'm wondering whether the implementation should implicitly grant 
package access for modules that a package in question was exported to in a 
qualified fashion? Now one ends up having to additionally add specific 
permissions which can easily be forgot.

Any comments? Shouldn't that be improved?

Best regards
Christoph

Re: An alternative to "restricted keywords"

[Remi Forax]

[CC JPMS expert mailing list because, it's an important issue IMO]

I've a counter proposition.

I do not like your proposal because from the user point of view, '^' looks like 
a hack, it's not used anywhere else in the grammar. 
I agree that restricted keywords are not properly specified in JLS. Reading 
your mail, i've discovered that what i was calling restricted keywords is not 
what javac implements :(
I agree that restricted keywords should be only enabled when parsing 
module-info.java
I agree that doing error recovery on the way the grammar for module-info is 
currently implemented in javac leads to less than ideal error messages.

In my opinion, both
   module m { requires transitive transitive; }
   module m { requires transitive; }
should be rejected because what javac implements something more close to the 
javascript ASI rules than restricted keywords as currently specified by Alex.

For me, a restricted keyword is a keyword which is activated if you are at a 
position in the grammar where it can be recognized and because it's a keyword, 
it tooks over an identifier.
by example for 
  module m { 
if the next token is 'requires', it should be recognized as a keyword because 
you can parse a directive 'required ...' so there is a production that will 
starts with the 'required' keyword.

so 
  module m { requires transitive; }
should be rejected because transitive should be recognized as a keyword after 
requires and the compiler should report a missing module name.
 
and
  module m { requires transitive transitive; }
should be rejected because the grammar that parse the modifiers is defined as 
"a loop" so from the grammar point of view it's like
  module m { requires Modifier Modifier; }
so the the front end of the compiler should report a missing module name and a 
later phase should report that there is twice the same modifier 'transitive'.

I believe that with this definition of 'restricted keyword', compiler can 
recover error more easily and offers meaningful error message and the 
module-info part of the grammar is LR(1).

regards,
Rémi

- Mail original -
> De: "Stephan Herrmann" 
> À: jigsaw-dev@openjdk.java.net
> Envoyé: Mardi 9 Mai 2017 16:56:11
> Objet: An alternative to "restricted keywords"

> (1) I understand the need for avoiding that new module-related
> keywords conflict with existing code, where these words may be used
> as identifiers. Moreover, it must be possible for a module declaration
> to refer to packages or types thusly named.
> 
> However,
> 
> (2) The currently proposed "restricted keywords" are not appropriately
> specified in JLS.
> 
> (3) The currently proposed "restricted keywords" pose difficulties to
> the implementation of all tools that need to parse a module declaration.
> 
> (4) A simple alternative to "restricted keywords" exists, which has not
> received the attention it deserves.
> 
> Details:
> 
> (2) The current specification implicitly violates the assumption that
> parsing can be performed on the basis of a token stream produced by
> a scanner (aka lexer). From discussion on this list we learned that
> the following examples are intended to be syntactically legal:
>module m { requires transitive transitive; }
>module m { requires transitive; }
> (Please for the moment disregard heuristic solutions, while we are
>  investigating whether generally "restricted keywords" is a well-defined
>  concept, or not.)
> Of the three occurrences of "transitive", #1 is a keyword, the others
> are identifiers. At the point when the parser has consumed "requires"
> and now asks about classification of the word "transitive", the scanner
> cannot possible answer this classification. It can only answer for sure,
> after the *parser* has accepted the full declaration. Put differently,
> the parser must consume more tokens than have been classified by the
> Scanner. Put differently, to faithfully parse arbitrary grammars using
> a concept of "restricted keywords", scanners must provide speculative
> answers, which may later need to be revised by backtracking or similar
> exhaustive exploration of the space of possible interpretations.
> 
> The specification is totally silent about this fundamental change.
> 
> 
> (3) "restricted keywords" pose three problems to tool implementations:
> 
> (3.a) Any known practical approach to implement a parser with
> "restricted keywords" requires to leverage heuristics, which are based
> on the exact set of rules defined in the grammar. Such heuristics
> reduce the look-ahead that needs to be performed by the scanner,
> in order to avoid the full exhaustive exploration mentioned above.
> A set of such heuristic is extremely fragile and can easily break when
> later more rules are added to the grammar. This means small future
> language changes can easily break any chosen strategy.
> 
> (3.b) If parsing works for error-free input, this doesn't imply that
> a parser will be able to give any