Migration of Integer to inline

Mateusz Romanowski romanowski.mateusz at gmail.com
Fri Dec 20 23:11:07 UTC 2019


Thanks for quick response.

As for Integer::new, some people (including me once) might still use the
constructor to bypass the IntegerCache.

The migration story could then include some Integer::valueOfUncached
factory for such usages.

I would love to see such method introduced with the constructor being made
synthetic (JDK-8236444).

Cheers.


W dniu piątek, 20 grudnia 2019 Brian Goetz <brian.goetz at oracle.com>
napisał(a):
>
>
>> If non-Object abstract class as superclass of inline class is allowed,
the
>> migration story for Optional seems easy.
>> It would be the same for Integer, if only there were no pesky public
>> Integer::new...
>
> These constructors have been deprecated since Java 9; and there has been
IDE support for migrating invocations of these to the appropriate factory
methods for at least a dozen years.  It is reasonable to deprecate them for
removal.
>
> As with `new Object()`, it is also possible to take heroic measures to
relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type,
though we're not ready to plunk for that yet (it's more complicated than
for Object.)
>
> Bytecode weaving (perhaps even at load time, with an agent) is indeed a
possible means of rewriting these dusty jars.
>
>>
>> Could you share any preliminary thoughts how the classfiles (found in
>> *dusty* jars) that use the Integer constructor would be treated?
>>
>> Is it feasible to have the bytecode weaved to replace the new-dup-init
>> sequence during class loading?
>>
>> Thanks,
>> Mateusz
>
>


More information about the valhalla-dev mailing list