> https://bugs.openjdk.java.net/browse/JDK-8232654
>
> Also just to summarize the discussion/objection from Seth Lytle. I think
> we've established that that it was a regression in JDK 10 that allowed
> that example to work. The method has always been specified to fail when
> the thread is not suspended.
>
> -Alan
>
>
>
emaining in the stack, esp if it was fast. Any
chance that that could get added to the stack walker API ?
On Thu, Oct 24, 2019 at 4:21 AM Alan Bateman wrote:
>
> On 23/10/2019 23:00, seth lytle wrote:
> > At least a couple appear to be recently active, though I don't have
57 AM Alan Bateman wrote:
>
> On 23/10/2019 16:25, seth lytle wrote:
> > With respect to "unable to find anything that uses it", a quick search
> > of the code that I have access to shows some usage, though everything
> > I looked at in any depth is either a test
With respect to "unable to find anything that uses it", a quick search
of the code that I have access to shows some usage, though everything
I looked at in any depth is either a test or a proxy, so there will be
source code changes required. I've never thought about what the right
way to handle pro
e of the field holding the
> lambda to java.lang.Object and see if it works... (It should if my
> memory serves me well :-)
>
> This is a known defect of Java serialization and is not specific to
> serialized lambda.
>
> There were some unsuccessful attempts to fix it during (
rs be defined in the same
> package - which implies the same classloader
On Mon, Mar 25, 2019 at 11:40 PM David Holmes
wrote:
> On 26/03/2019 1:06 pm, seth lytle wrote:
> > i still get the same stack trace after breaking the example out into two
> > files. does that suff
s.newInstance();
myCode.run();
}
}
On Mon, Mar 25, 2019 at 10:34 PM David Holmes
wrote:
> Hi Seth,
>
> On 26/03/2019 12:16 pm, seth lytle wrote:
> > i haven't changed the assignment from the original test case (which was
> > accepted as valid at the time). i ha
5, 2019 at 9:34 PM David Holmes
wrote:
> Hi Seth,
>
> On 26/03/2019 11:22 am, seth lytle wrote:
> > if a lambda is a field and captures `this`, and it's deserialized into a
> > new class loader, it throws a ClassCastException.
>
> Not sure I follow. If you load a
if a lambda is a field and captures `this`, and it's deserialized into a
new class loader, it throws a ClassCastException. i came across this bug
independently while writing a test, but then found an old openjdk bug with
a similar issue and tweaked the test case (source below). my version
differs o
for reporting an error is to prevent the "wrong" class being
> used!
>
> -- Jon
>
>
> On 09/14/2018 10:14 AM, seth lytle wrote:
>
>> this behavior of throwing an error if the class is found twice on the
>> classpath strikes me as unusual - afaik, in all o
this behavior of throwing an error if the class is found twice on the
classpath strikes me as unusual - afaik, in all other cases, java is fine
with finding multiple implementations on the classpath and uses the first
found (similar to the unix path, which also allows overriding by providing
an exp
david lloyd wrote:
> AFAIK any code would expect that resources available as streams would
> generally
also be available as URLs
starting with java 9, the javadocs for getResource (but not for
getResourceAsStream) specifically allow returning null if "a URL could not
be constructed to locate the
JEP 330 (launch single-file source programs) uses a MemoryClassLoader. the
compiled bytecode is stored in byte arrays in memory and is never written
to file. currently, the bytecode is not exposed as resources and it would
be advantageous to do so (enabling the use of eg ASM to modify the classes
t
13 matches
Mail list logo
