[statics] allowing static initializers in interfaces?
Remi Forax
forax at univ-mlv.fr
Wed Nov 18 10:58:07 UTC 2020
----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 18 Novembre 2020 09:07:18
> Objet: Re: [statics] allowing static initializers in interfaces?
> +1 from me too, and generally to heal the rift.
> The inability to put private classes (and other “stuff”)
> in an interface makes it hard to support canonical
> algorithms in default methods, if they need auxiliary
> types.
yes,
another example, in the patch introducing the new random generator API currently under review, there is this method
default float nextFloat() {
return (nextInt() >>> 8) * 0x1.0p-24f;
}
which a good example of why we also need private static final fields in interface.
Rémi
>
>> On Nov 17, 2020, at 6:03 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>> Hi,
>> now that the work on allowing static members in nested declarations [1] is
>> wrapping up, I'm wondering if we could add treatment for one more case: static
>> initializers in interfaces. This seems a case where the static compiler is
>> already inserting static blocks (to initialize any static fields an interface
>> might declare), but where the JLS is currently forbidding interfaces from
>> having an explicit static initializer block in the source code. This make e.g.
>> initialization of fields which might throw exceptions (e.g. method handles) not
>> possible inside interfaces. While I realize this is a corner case, I thought it
>> would still be worth asking the question :-)
>>
>> Cheers
>> Maurizio
>>
>> [1] - https://git.openjdk.java.net/jdk/pull/571
More information about the amber-spec-observers
mailing list