On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
> `java.lang.invoke.MemberName$Factory::resolve` and
>
On Tue, 21 May 2024 20:14:41 GMT, Jorn Vernee wrote:
>> Class loading triggered by `Class.forName()` call is at the core of
>> `isTypeVisible`. (The rest is fast path checks.) It's what makes
>> `isTypeVisible` query idempotent.
>>
>> I can definitely name it differently (e.g,
On Tue, 21 May 2024 18:02:45 GMT, Vladimir Ivanov wrote:
> I can definitely name it differently (e.g, ensureTypeVisible), but making a
> separate class loading pass across signature classes doesn't make much sense.
Ok, in that case I suggest also renaming `MemberName::checkForTypeAlias`, maybe
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
>
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
>
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
>
JVM routinely installs loader constraints for unloaded signature classes when
method resolution takes place. MethodHandle resolution took a different route
and eagerly resolves signature classes instead (see
`java.lang.invoke.MemberName$Factory::resolve` and
10 matches
Mail list logo