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 acc
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,
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)
requ
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()
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 ModuleLay
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: addPa
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
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/d7d
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/cod
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/
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/re
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/resourc
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/Par
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:/
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, a
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: 55
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 re
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 : {
On 12 May 2017 at 17:37, Stephen Colebourne wrote:
> 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
On 05/12/2017 09:37 AM, Stephen Colebourne wrote:
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 Module
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 alternat
#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 unrea
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
> module guava {
> requires transient com.google.common;
> }
>
I suspect you mean 'transitive' here.
Sander
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
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 o
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 M
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 la
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:
[.
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 miserab
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 tra
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
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
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
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 check
35 matches
Mail list logo
