EG meeting, 2020-11-04

Remi Forax forax at
Thu Nov 5 09:42:01 UTC 2020

----- Mail original -----
> De: "daniel smith" <daniel.smith at>
> À: "valhalla-spec-experts" <valhalla-spec-experts at>
> Envoyé: Mercredi 4 Novembre 2020 19:18:02
> Objet: Re: EG meeting, 2020-11-04

>> On Nov 3, 2020, at 4:53 PM, Dan Smith <daniel.smith at> 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.

Not sure new Object() is simpler because in term of bytecode INVOKEPECIAL Object <init>()V has two meanings (init call and super call) and we want to re-write only the former but not the later, while INVOKEPECIAL Integer <init>(I)V can not be used as a super call.


More information about the valhalla-spec-observers mailing list