Migration of Integer to inline

[Brian Goetz]

If we can successfully migrate Integer to be a value type, the cache 
goes away, since the instances no longer have identity.

On 12/20/2019 6:11 PM, Mateusz Romanowski wrote:
> 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 
> <mailto: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
> >
> >