My bad.
In the modifications of the original code, I proposed to replace
URL classFileB =
TestLoading.class.getResource(TestLoading.class.getSimpleName() +
"$ChildClass.class");
with
URL classFileB =
TestLoading.class.getResource(ChildClass.class.getSimpleName() + ".class");
On 25/05/2023 7:21 pm, Raffaello Giulietti wrote:
Yes, ChildClass.class is removed from the filesystem.
And here's, the relevant info when running with -Xlog:class+init,
showing that verification succeeds for both TestLoading$ObjectReturner
and TestLoading$BaseClassReturner:
loading:
Yes, ChildClass.class is removed from the filesystem.
And here's, the relevant info when running with -Xlog:class+init,
showing that verification succeeds for both TestLoading$ObjectReturner
and TestLoading$BaseClassReturner:
loading: TestLoading$ObjectReturner...
On 25/05/2023 12:34 am, Raffaello Giulietti wrote:
As mentioned in my previous email, if you move the member class
ChildClass out of TestLoading (out of the nest), and make it a top-level
class like
public class ChildClass extends TestLoading.BaseClass {
}
and change
URL
As mentioned in my previous email, if you move the member class
ChildClass out of TestLoading (out of the nest), and make it a top-level
class like
public class ChildClass extends TestLoading.BaseClass {
}
and change
URL classFileB =
- Original Message -
> From: "David Holmes"
> To: "Raffaello Giulietti" , "core-libs-dev"
>
> Sent: Wednesday, May 24, 2023 12:23:24 AM
> Subject: Re: Classes used in method body are loaded lazily or eagerly
> depending on method return type
> On 24/05/2023 12:50 am, Raffaello
- Original Message -
> From: "Сергей Цыпанов"
> To: "core-libs-dev"
> Sent: Tuesday, May 23, 2023 1:20:44 PM
> Subject: Classes used in method body are loaded lazily or eagerly depending
> on method return type
> Hello,
Hello,
>
> originally this question was asked here:
>
On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
I think the problem here is that you are deleting a class in a nest.
During the verification of BaseClassReturner.getObject(), access control
(JVMS, 5.4.4, second half) determines that the nest is broken, as
ChildClass is not present anymore.
On 24/05/2023 5:04 am, Сергей Цыпанов wrote:
Hi,
Verification can require classes to be loaded to perform the
verification - see JVMS 4.10 for all the details.
sorry, I still don't get it completely. Here's the byte code for
ObjectReturner.getObject():
// access flags 0x1
public
I think the problem here is that you are deleting a class in a nest.
During the verification of BaseClassReturner.getObject(), access control
(JVMS, 5.4.4, second half) determines that the nest is broken, as
ChildClass is not present anymore.
If you move ChildClass out of TestLoading so that
Hi,
On 23/05/2023 9:20 pm, Сергей Цыпанов wrote:
Hello,
originally this question was asked here:
https://stackoverflow.com/q/76260269/12473843,
the code sample for reproduction will be put below or can be found via the link
The issue is about eager/lazy loading of a class depending on method
Hello,
originally this question was asked here:
https://stackoverflow.com/q/76260269/12473843,
the code sample for reproduction will be put below or can be found via the link
The issue is about eager/lazy loading of a class depending on method return
type.
If one runs the code below with Java
12 matches
Mail list logo
