----- Mail original ----- > De: "daniel smith" <daniel.sm...@oracle.com> > À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > 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.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. 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. Rémi
