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
Thanks David for the detailed response!
On Mon, Oct 8, 2018 at 7:27 AM David Lloyd wrote:
> I think it's pretty reasonable to
> document that user programs that wish to have context-sensitive
> loggers should grant the "getStackWalkerWithClassReference"
> RuntimePermission to the logging JAR/mod
On 08/10/2018 15:37, Luke Hutchison wrote:
:
I looked for documentation on how to grant runtime permissions for a
specific module via the commandline or in a policy file, but I couldn't
figure out how to do this. The closest I found was "grant codeBase "
-- is this the right mechanism, used with
This is the issue that Thomas Watson brought up here on Friday. If
defineModulesWithXXX is used to create a module layer and it contains a
module that reads an automatic module mapped to a different class loader
(same layer or parent layer) then the class loader delegation isn't
setup. This
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
>> behaviors based on run t
On 10/8/18 7:46 AM, Alan Bateman wrote:
This is the issue that Thomas Watson brought up here on Friday. If
defineModulesWithXXX is used to create a module layer and it contains
a module that reads an automatic module mapped to a different class
loader (same layer or parent layer) then the
