Changeset: 7e790234d48f
Author:mchung
Date: 2017-04-26 19:28 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7e790234d48f
Replace jmod --os-name/--os-arch option with --target-platform
! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/sp
Changeset: c5621b8c5c91
Author:mchung
Date: 2017-04-26 19:28 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c5621b8c5c91
Replace jmod --os-name/--os-arch option with --target-platform
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java
!
src/jdk.jlink/s
On 26 April 2017 at 17:27, wrote:
> I think I need to reconsider my previous conclusion that explicit modules
> that depend upon automatic modules should never be published for broad
> use [2].
>...
> The only remaining objection seems to be the aesthetic one, i.e., the
> fact that the name of an
On 26 April 2017 at 19:35, Alan Bateman wrote:
> On 26/04/2017 18:35, Stephen Colebourne wrote:
>
>> :
>> - an incomplete module defines as many dependencies as it can
>> - an incomplete module also depends on the classpath
>> - the current automatic module concept ceases to exist
>> (an incomplet
Changeset: a3eb50edd55f
Author:alanb
Date: 2017-04-26 21:09 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3eb50edd55f
Reduce ModuleTarget to one target platform value
! src/java.base/share/classes/java/lang/module/Configuration.java
! src/java.base/share/classes/java/l
Changeset: 4d2852920d34
Author:alanb
Date: 2017-04-26 21:09 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4d2852920d34
Reduce ModuleTarget to one target platform value
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java
!
src/jdk.jdeps/share/cl
Just a quick note on some recent updates to the command line options.
Since early builds, `--list-modules` has allowed a module name to be
specified so that the option describes a module rather than list the
observable modules. This was always a bit strange and has finally been
separated into
On 26/04/2017 18:35, Stephen Colebourne wrote:
:
- an incomplete module defines as many dependencies as it can
- an incomplete module also depends on the classpath
- the current automatic module concept ceases to exist
(an incomplete module is not an automatic module, as it doesn't get to
read a
On 26 April 2017 at 17:27, wrote:
> 2017/4/25 5:08:21 -0700, Stephen Colebourne :
>> As discussed before, removing automatic modules and allowing modules
>> to have partially specified dependencies [1] 1b allows projects to
>> migrate to modules immediately. This would be a huge win. Any project
On Wed, Apr 26, 2017 at 12:27 PM, wrote:
> If one of those automatic modules is modularized later on, and given a
> different name, then how is having to fix that materially different from
> having to fix code that was using a package that's no longer exported?
> If anything it might actually be
On 04/26/2017 11:27 AM, mark.reinh...@oracle.com wrote:
2017/4/25 5:08:21 -0700, Stephen Colebourne :
On 24 April 2017 at 19:54, wrote:
An explicit module that depends upon one or more modules that are
automatic today is, itself, no more stable than those automatic modules.
It could be broken
2017/4/25 5:08:21 -0700, Stephen Colebourne :
> On 24 April 2017 at 19:54, wrote:
>> An explicit module that depends upon one or more modules that are
>> automatic today is, itself, no more stable than those automatic modules.
>> It could be broken when those automatic modules are modularized
>>
On 26/04/2017 16:31, fo...@univ-mlv.fr wrote:
:
4. create a classloader
ClassLoader classLoader = new ClassLoader(parentClassLoader()) { /* make
defineClass more visible */};
5. create your own layer [4]
ModuleLayer layer = boot.defineModulesWithOneLoader(cf, classloader;
6
- Mail original -
> De: "Matej Novotny"
> À: "Remi Forax"
> Cc: "Alan Bateman" , jigsaw-dev@openjdk.java.net,
> "Tomas Remes" , "Martin
> Kouba"
> Envoyé: Mercredi 26 Avril 2017 16:04:08
> Objet: Re: setAccessible() alternative with Jigsaw - feedback on Lookup
>> You can spin one modul
On 26/04/17 15:04, Matej Novotny wrote:
>
>> You can spin one module per package, by creating one ModuleLayer per package,
>> not unlike j.l.r.Proxy does.
>
> Don't know a bit about it, but it sounds like a way worth exploring.
> Would you have a pointer towards some code showing how to deal with
> You can spin one module per package, by creating one ModuleLayer per package,
> not unlike j.l.r.Proxy does.
Don't know a bit about it, but it sounds like a way worth exploring.
Would you have a pointer towards some code showing how to deal with
ModuleLayers?
Also checking on j.l.r.Proxy, it
Just to add a note that came up in a twitter conversation.
Modules are not artifacts. [1]
ergo, module names are usually not artifact names
yet, automatic module names are derived from artifact names
Its no wonder that I have seen lots of confusion between modules and
artifacts, Jigsaw itself is
Changeset: f5ba193588e2
Author:alanb
Date: 2017-04-26 14:10 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f5ba193588e2
8175819: OS name and arch in JMOD files should match the values as in the
bundle names
! common/autoconf/generated-configure.sh
! common/autoconf/platform
Changeset: 750ed72c847b
Author:mchung
Date: 2017-04-20 08:00 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/750ed72c847b
8175819: OS name and arch in JMOD files should match the values as in the
bundle names
Reviewed-by: erikj, ihse
! src/jdk.jlink/share/classes/jdk/too
On 26/04/2017 12:55, Juergen Hoeller wrote:
:
You're saying that such transitive resolution of automatic modules
happens implicitly now, i.e. "requires spring.context" implicitly
makes spring.core visible to the application module when both
spring.context and spring.core are automatic module
Alan,
In my last round of testing, application modules had to declare not only
"requires spring.context" but also "requires spring.core", since
spring.context - as an automatic module - couldn't bring in spring.core
transitively. Explicitly adding those through --add-modules is a way out
that I'm
Changeset: aa2f7b554c9b
Author:alanb
Date: 2017-04-26 07:46 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aa2f7b554c9b
Drop need to have PRIVATE access to have been dropped
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! test/java/lang/invoke/DefineC
On 25/04/2017 09:48, Juergen Hoeller wrote:
:
For the time being, we'll have to keep focusing on the use of our framework
jars as automatic modules... which works fine for us so far. Even if the
lack of transitive dependencies is a bit of a nuisance, there is enough
value for somebody choosing
On 26/04/2017 09:14, Gunnar Morling wrote:
It's described in the JavaDoc of ModuleFinder#of():
http://download.java.net/java/jdk9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-
Not sure whether there's another more authoritative source.
That is the right link and
It's described in the JavaDoc of ModuleFinder#of():
http://download.java.net/java/jdk9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-
Not sure whether there's another more authoritative source.
2017-04-26 10:08 GMT+02:00 Cédric Champeau :
> Is there a specification of
Is there a specification of how the automatic module name is built? I'm
asking because we will likely have to do something like that in Gradle, and
we cannot use JDK 9 specific APIs for this (Gradle can run on JDK 8, for
example, while the compiler would be forked to use JDK 9, so JDK 9 APIs may
no
26 matches
Mail list logo
