> On Nov 3, 2020, at 4:53 PM, Dan Smith <daniel.sm...@oracle.com> wrote: > > The next EG Zoom meeting is Wednesday, 5pm UTC (12pm EST, 9am PST). > > We'll talk about "Source code analysis: calls to wrapper class constructors", > including tentative plans for helping existing clients of Integer.<init>, > Double.<init>, etc., migrate to a VM in which these are primitive classes.
Summarizing: consensus that the proposed path (lean hard on deprecation, but also provide bytecode rewrite tooling) is the "least bad" option. But we discussed some additional areas of concern/risk: - The proposal is to perform bytecode rewrites as an opt-in—e.g., via an agent provided at the command line. But if it turns out that it's quite common to need to use this incantation, this could be a major source of friction to adoption. On the other hand, if we make it the default behavior, we're talking about changing JVM semantics. That might be possible, but there are reasons to be wary of burning this behavior into JVMS. - It's possible people will be frustrated that sources written for pre-9 javac will fail to compile in the primitive classes version of javac. Ideally, they will first try to compile on 11, 17, etc., and see the warnings. In a sense, this is just how deprecation works, but it's also true that this is an especially sensitive/widespread API being deprecated. The solution would be to allow javac to do something special with 'new Integer', or perhaps to just keep the public constructors in the primitive class (as a "discouraged" but available API point). - Deprecation warnings are good for source, not so good for binary dependencies. The ecosystem could really use better tooling to flag usages of deprecated APIs, including at build time (IDEs, Maven, etc.) and runtime (JVM warnings). For the first two, it's fair to say that it's hard to predict how those risks will play out, but we should keep them in mind until the release gets closer. Another idea, briefly discussed: if this plan works for 'new Integer', might it also be best for 'new Object'? We're more comfortable baking special-case behavior into the JVM in that case, because the rewrite is simpler, but we could revisit that decision.
