Source code analysis: calls to wrapper class constructors

[Dan Smith]

> On Oct 27, 2020, at 2:00 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Three remarks:
> - the compiler can warn because a code is using new Integer(value) or warn because the compiler will automatically transform all new Integer(value) to Integer.valueOf() once Valhalla is integrated,
>  i prefer the second solution, having a warning message saying that in the future new Integer() will not be supported and that all new Integer(...) will be transformed by the compiler automatically to Integer.valueOf(). 

I think the idea here is that if the compiler were doing this today, it would reduce the amount of binaries that will fail in the future. But... it won't eliminate the problem. I think we'd still need to do something about binaries that are *already* published (e.g., JUnit 4.12), or that target a pre-16 JDK.

So given that a workaround for binaries will exist, there's not a lot to be gained by complicating the source-level story. And in the minus column, some areas of concern:

- We'd have to change the language in 16 to special-case what class instance creation expressions mean.

- We'd be breaking behavioral compatibility, with no way to opt out (if, say, you need unique identities, and don't plan to deploy on future JDKs).

- There's no change in the compile-time experience—using either deprecation or these special warnings, you'd be stuck with warnings until you rewrote your code.

Treating this as a standard application of deprecation, with behavioral changes triggered by source code changes, seems like a more attractive solution.

> - the introduction of the strong encapsulation in 9 was a very similar challenge, the first thing to do is to raise awareness, having a warning at runtime (so emitted by the VM) per callsite using new Wrapper(...)
>  will help a lot. People can detect easily if they are using a dependency that use something that will not be backward compatible (this warning should be emitted by Java 16+, because there is no point to wait
>  and because of JEP 396, there will be a second wave of people wanting to update the library they maintain, so they can fixed both issues in one pass.

Besides javac, one out-of-the-box tool we already have is jdeprscan, which since 9 reports any wrapper constructor calls in a given jar file.

I'm not sure whether there's a mechanism in HotSpot to generate warnings about deprecated APIs at link/run time. It does seem like it would be a reasonable feature...

> - IDE should inspect the jars downloaded by Maven and Gradle, and report the use of deprecated for removal APIs, again to raise awareness,
>  a warning directly on the tag dependency in the POM saying that this dependency (or one of it's sub-dependencies) is using deprecated for removal APIs will help a lot. 

Yes, IDEs providing their own jdeprscan-style diagnostics would be quite helpful.