Ah, thanks for clarifying, I missed those exceptions.
On Fri, Oct 19, 2018 at 5:53 PM Alex Buckley
wrote:
> On 10/19/2018 4:09 PM, Luke Hutchison wrote:
> > In JLS section 4.1 ("The ClassFile structure") for SE 11, it states:
>
> You mean JVMS, not JLS. See the tex
In JLS section 4.1 ("The ClassFile structure") for SE 11, it states:
super_class
For a class, the value of the super_class item either must be zero or must
be a valid index into the constant_pool table. If the value of the
super_class item is nonzero, the constant_pool entry at that index must be
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 Fri, Oct 5, 2018 at 1:58 PM Ralph Goers wrote:
> I didn’t write this particular test. I will have to find it.
>
I'm curious to see the test as well, especially to see what the
"defaultJava8" test is. Is that a method for getting the stack frames using
Exception::getStackTrace or something?
O
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.
>
This is interesting -- how much slower is StackWalker in these situations,
and under what condition is there a speed difference?
Have you seen Secur
If you need to read the stack in a manner that is backwards compatible with
JDK 8 or earlier, there's also the following mechanism for getting the call
stack, by creating a SecurityManager:
https://github.com/classgraph/classgraph/blob/master/src/main/java/io/github/classgraph/utils/CallStackReade
JEP 238 says "JAR metadata, such as that found in the MANIFEST.MF file and
the META-INF/services directory, need not be versioned." However, if a
manifest file is present in the base layer *and* a version layer, what are
the correct semantics? e.g.
META-INF/MANIFEST.MF :
Multi-Release: true
X: 1
On Sun, Sep 30, 2018 at 2:33 AM Alan Bateman
wrote:
> If you are running on JDK $N then an entry in META-INF/versions/$N will
> override an entry of the same name in versioned sections < $N as well as
> the base section. The JarFile javadoc and JEP 238 describe this in detail.
> One mental model
Thanks for the helpful explanation.
On Sun, Sep 30, 2018 at 2:33 AM Alan Bateman
wrote:
> On 30/09/2018 08:57, Luke Hutchison wrote:
>
> :
>
> I have a related question about this specifically. I just added
> multi-release jar support to ClassGraph (
> https://github.com/
On Sun, Sep 30, 2018, 1:35 AM Alan Bateman wrote:
> I don't recall the discussion here that lead to the advice to put the
> module-info.class in META-INF/versions/9 - if you can find the mail
> thread or even the subject line of the discussion then it would help
> provide the context. In general,
the use of decompressed sizes in the
loading of resources from runtime images that were created with compression.
On Wed, Aug 8, 2018 at 6:22 AM Alan Bateman wrote:
> On 08/08/2018 06:19, Luke Hutchison wrote:
> > :
> >
> > (2) size is used directly without restriction,
email, requesting an API call to get the
size hint from the corresponding ZipEntry.
Did you have comments on any of the observations in my other message that
the size of a ZipEntry cannot be trusted, or can be -1?
On Wed, Aug 8, 2018 at 1:40 AM Alan Bateman wrote:
> On 08/08/2018 06:16, Luke H
The uncompressed size of a resource is used in
BasicImageReader#getResource(ImageLocation), which calls readBuffer(offset,
uncompressedSize) . The readBuffer method then does two or three things
that seem incorrect if the size is obtained from ZipEntry#getSize():
(1) size < 0 is rejected, but Zip
The current ModuleReader API has methods list(), open(String name), and
read(String name). However, there is no way to get the length (file size)
of a resource short of opening or reading the whole resource, then
examining the number of bytes read or mapped. This can lead to unnecessary
resizing of
Hi Alan, I was just wondering if you could please comment on this issue I
raised:
On Mon, Jun 25, 2018 at 6:00 PM Luke Hutchison wrote:
> I'm assuming that since more than one module may define classes in the
> same package, it is possible to have the same class defined multiple
med that ArrayDeque had O(size()) time for
insertion at the head -- but I just looked at the implementation and it's
O(1) -- very clever :-)
On Fri, Jun 15, 2018 at 8:50 AM Alan Bateman
wrote:
> On 15/06/2018 04:37, Luke Hutchison wrote:
> > :
> >
> > This code represents a p
Hi, I noticed that the method ModuleLayer#layers() uses the following code
to get the module layers in resolution order:
/**
* Returns an ordered stream of layers. The first element is this layer,
* the remaining elements are the parent layers in DFS order.
*
* @implNote Fo
ike there are lots of obvious omissions in the API, from an
enumeration / scanning point of view. Or am I missing something?
Thanks,
Luke Hutchison
18 matches
Mail list logo
