Re: Separate logging for JPMS module/layer

On Mon, Oct 8, 2018 at 9:38 AM Luke Hutchison wrote: > On Mon, Oct 8, 2018 at 7:27 AM David Lloyd wrote: >> I think a single clear >> behavior plus a documentation note would result in a better user >> experience than falling back through multiple potentially differing >

Re: Separate logging for JPMS module/layer

On Fri, Oct 5, 2018 at 3:46 PM Luke Hutchison wrote: > > In my own code, I used StackWalker::forEach rather than StalkWalker::walk, > since the stream API has such high overhead. Even lambdas have a high > startup overhead for some reason (I think it was 20ms of incurred latency > when you first u

Re: Separate logging for JPMS module/layer

On Fri, Oct 5, 2018 at 10:12 AM Ralph Goers wrote: > > On Oct 5, 2018, at 1:10 AM, Luke Hutchison wrote: > > > > On Thu, Oct 4, 2018, 10:27 PM Ralph Goers > > wrote: > > Yes, we have found in some situations using the SecurityManager is faster > > than StackWalker. > >

Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

On Thu, Jul 19, 2018 at 1:12 PM Alan Bateman wrote: > > On 19/07/2018 16:27, David Lloyd wrote: > > : > > When running on Java 9 or later, this code relies on being able to > > reference java.se, and more importantly, all of the modules that it > > includes, which w

Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

On Thu, Jul 19, 2018 at 10:03 AM Alan Bateman wrote: > > On 19/07/2018 15:14, David Lloyd wrote: > > I've run into a problem with the change in java.se resolution. There > > is, from what I can tell, no way to add the java.se module to the > > runtime that doesn'

Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

I've run into a problem with the change in java.se resolution. There is, from what I can tell, no way to add the java.se module to the runtime that doesn't also break on Java 8. The "jdk.module.*" properties are blocked off so that approach doesn't work. Any recommendations? What about a way fo

Re: Module "java.se" is now missing from the boot layer

I see now that the original change applied to classpath mode. I'm going to go have some caffeine now, thanks. On Thu, Jul 12, 2018 at 9:43 AM David Lloyd wrote: > > I guess this was a result of: > > > The webrev with the proposed changes is here: > >http://cr.openj

Re: Module "java.se" is now missing from the boot layer

rambling thread, I'm juggling a few things here) On Thu, Jul 12, 2018 at 9:40 AM David Lloyd wrote: > > It does work if you manually add "java.se" to the command line via > "--add-modules" though. Was this an intentional change? > On Thu, Jul 12, 2

Re: Module "java.se" is now missing from the boot layer

It does work if you manually add "java.se" to the command line via "--add-modules" though. Was this an intentional change? On Thu, Jul 12, 2018 at 9:37 AM David Lloyd wrote: > > In the most recent EA, calling > ModuleLayer.boot().findModule("java.se") no

Module "java.se" is now missing from the boot layer

In the most recent EA, calling ModuleLayer.boot().findModule("java.se") now appears to return an empty Optional, which is a change in behavior compared to 9/10 AFAICT. However the module does appear in the output of "java --list-modules". -- - DML

Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

FWIW I strongly support this change. On Tue, Jun 19, 2018 at 3:32 AM Alan Bateman wrote: > > > JEP 261 details how the default set of root modules is computed when > compiling code in the unnamed module or when running code and the main > class is loaded from the class path. I'd like to re-visit t

Re: ModuleLayer#layers() and Configuration#configurations() produces non-topological ordering

On Thu, Jun 14, 2018 at 10:37 PM, Luke Hutchison wrote: > The list allLayers should be changed to a LinkedList, allowing nodes to be > pushed onto the beginning of the list, so that the ordering doesn't have to A small quibble: LinkedList should normally never be used. You can push things on to

Re: Cyclic dependencies during multi-module compilation

I still consider this to be a non-bug. The cycle check has absolutely no useful purpose other than "scratching an itch". On Tue, May 8, 2018 at 3:01 AM, Nicolai Parlog wrote: > Hi! > > In early access builds, multi-module compilation would fail if there was > a dependency cycle between the invo

Proposed convention for multi-release source JARs

Debugging multi-release JARs can be a pain, because their corresponding sources generally do not include the multi-release overlays. I'd like to propose a convention for multi-release source JARs. AFAIK there is no specification for source JARs, but Maven and other build tools commonly output sou

Re: Some points on JPMS/Jigsaw after he modularised some code (from Stephen Colebourne)

On Fri, Mar 23, 2018 at 8:49 AM, Stephen Colebourne wrote: > On 23 March 2018 at 13:17, David Lloyd wrote: >> On Fri, Mar 23, 2018 at 7:51 AM, Stephen Colebourne >> wrote: >>> One approach is to say that modular jar files are always treated as >>> named module

Re: Some points on JPMS/Jigsaw after he modularised some code (from Stephen Colebourne)

On Fri, Mar 23, 2018 at 7:51 AM, Stephen Colebourne wrote: > One approach is to say that modular jar files are always treated as > named modules: > > - a modular jar on the class-path is treated as being named, not part > of the unnamed module It is therefore encapsulated, but depends on the > unn

Re: Some points on JPMS/Jigsaw after he modularised some code (from Stephen Colebourne)

On Fri, Mar 23, 2018 at 5:19 AM, Martijn Verburg wrote: > Hi All, > > Stephen's comments are in his blog post: http://blog.joda.org/2018/03/j > pms-negative-benefits.html > > He does raise some interesting points. Perhaps it's worth spending some > time before 11 is out to see if there is a combi

Re: Qualified exports/opens and services

On Thu, Jan 4, 2018 at 8:18 AM, Nicolai Parlog wrote: > Hi! > > First of all, happy new year, everybody. > > I got a question regarding qualified exports/opens and services. I > thought I once read a proposal that a service consumer that some > packages are exported or opened to could "forward" t

Re: reasons to add readability edges when creating layer

On Sun, Dec 31, 2017 at 10:06 AM, Michał Zegan wrote: > Is that planned to be added? Or even needed? I wanted to compare jpms > api to jboss-modules and seems to me that jboss-modules does not have > the dependency modification capability at all at the first glance. JBoss Modules does allow modif

Re: ReflectionFactory is not sufficient to support custom serialization libraries

On Tue, Dec 19, 2017 at 1:01 PM, Alan Bateman wrote: > On 19/12/2017 18:45, David Lloyd wrote: >> >> The ReflectionFactory class which was introduced for the purposes of >> supporting custom serialization libraries is not sufficient to the >> task by itself, des

ReflectionFactory is not sufficient to support custom serialization libraries

The ReflectionFactory class which was introduced for the purposes of supporting custom serialization libraries is not sufficient to the task by itself, despite what was implied by [1]. While it allows invocation of the various non-public serialization-related methods that are exposed by classes, i

Re: Patterns for libraries to access private state of user modules

On Mon, Nov 13, 2017 at 10:03 AM, Gunnar Morling wrote: > Hi, > > Libraries such as Hibernate often need to access private state of classes > from other modules (e.g. when using field access for JPA entities). > > [...] I can't see how a utility > method in my library could obtain the Lookup, as M

Re: Module naming for logging implementations

On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne wrote: > For most service providers, option 2 is obvious, however for logging > it is generally the case that only one implementation should be > present. If all the jar files that implement a specific logging API > had the same module name (opti

Re: java.lang.annotation.Generated

On Wed, Sep 20, 2017 at 7:49 AM, Alan Bateman wrote: > On 20/09/2017 13:43, Stephen Colebourne wrote: >> >> As per this email: >> >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011365.html >> the idea was to add a new annotation `java.lang.annotation.Generated` >> to replace th