Factory methods named <init> are currently only allowed in inline types and their return type must match either its holder, or, for inline hidden classes, java.lang.Object. These restrictions should be removed. Instead, factory methods should be required to be static and have a non-null return type, but allowed in interfaces and identity classes, along with inline types.

email from jrose:

I am still in favor of as few restrictions as possible on the new uses of the old name (<init>).

That approach leads to more usability and less cost developing spec, implementation,
and testing.

Specifically, if we recycle the name <init>, if it is defined or use as a static method,
it should not be subject to any of the restrictions it has currently.

This means, as far as the JVM is concerned, it can serve any purpose in any
translation strategy or any classfile, when it is invoked by invokestatic or
defined with ACC_STATIC.

I suppose somebody could say, “but it’s risky and expensive to allow random uses.”
I disagree. If we are going to allow *some* new uses, toolchains will have to
accept those new uses. From most points of view along the toolchains, those
new uses will look random and arbitrary even if there is some rule restricting
them. The cost of introducing any change, at all, ripples through the tool chain,
and making it slightly smaller or larger has no effect at most points. If we are
going to buy a new use for <init> (which Valhalla requires) let’s buy the most
we can for the work we have to do.

In particular, I want to use these new factory methods for *identity methods*,
in a future translation strategy which de-emphasizes the new/dup/init dance,
which is a recurrent source of security and performance problems.