Native methods in unnamed classes

[Remi Forax]

----- Original Message -----
> From: "Jim Laskey" <james.laskey at oracle.com>
> To: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Tagir Valeev" <amaembo at gmail.com>, "amber-spec-experts" <amber-spec-experts at openjdk.org>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Thursday, July 20, 2023 11:34:04 AM
> Subject: Re: Native methods in unnamed classes

> I think we will be moving toward stabilizing the class name (based on source
> file name) in the next round.
> 
> 📱


+1

Rémi

> 
>> On Jul 20, 2023, at 6:20 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>> 
>> Good point Tagir.
>> 
>> IMHO this is something that needs to be looked at. While it's true that the
>> compiler will have to come up with a name for the class, there's no guarantee
>> anywhere that such a name will be stable. E.g. perhaps the Java compiler can
>> change the name of the class depending on the contents it saw at the time of
>> compiling (we don't do this, but JLS doesn't say it can't be done). Which then
>> would leave you with a set of *unstable* native methods.
>> 
>> Maurizio
>> 
>>> On 20/07/2023 10:17, Tagir Valeev wrote:
>>> Hello!
>>> 
>>> A quick question about unnamed classes specification draft [1]. I
>>> don't see that native methods are explicitly forbidden inside unnamed
>>> classes. If they are allowed, it's not quite clear how to define the
>>> name of the corresponding method in the native library according to
>>> [2], as the binary name of an unnamed class can be arbitrarily defined
>>> by java compiler (JLS 13.1). Or is this not a problem?
>>> 
>>> With best regards,
>>> Tagir Valeev
>>> 
>>> [1]
>>> https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
>>> [2]
> >> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names