[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-experts mailing list