----- Original Message ----- > From: "Jim Laskey" <[email protected]> > To: "Maurizio Cimadamore" <[email protected]> > Cc: "Tagir Valeev" <[email protected]>, "amber-spec-experts" > <[email protected]>, "amber-spec-experts" > <[email protected]> > 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 >> <[email protected]> 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
