From daniel.smith at oracle.com Tue Nov 3 23:53:54 2020 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 3 Nov 2020 16:53:54 -0700 Subject: EG meeting, 2020-11-04 Message-ID: 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., Double., etc., migrate to a VM in which these are primitive classes. My understanding is that some Oracle JVM engineers may not be able to attend due to a meeting conflict. That's fine, as this is mainly a libraries and platform evolution topic. From john.r.rose at oracle.com Wed Nov 4 00:18:56 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 3 Nov 2020 16:18:56 -0800 Subject: Source code analysis: calls to wrapper class constructors In-Reply-To: <78928896.1327867.1603915515955.JavaMail.zimbra@u-pem.fr> References:

<1230117334.1075618.1603877159693.JavaMail.zimbra@u-pem.fr> <05C60E88-1D92-4C8F-87F5-C1E751730F5C@oracle.com> <78928896.1327867.1603915515955.JavaMail.zimbra@u-pem.fr> Message-ID: <5DD1A8CC-66D9-4AE5-9120-6DDD2E20F522@oracle.com> On Oct 28, 2020, at 1:05 PM, forax at univ-mlv.fr wrote: > > I've never seen such bytecode shapes but I don't think i've ever seen a classfile compiled with a version which was less that Java 1.2. ?I?ve seen bytecode shapes, such bytecode shapes as would freeze the marrow. It was dark and rainy, that night I first confronted the Bytecode Obfuscator. They say he no longer stalks this world, but tell me: Why do I clutch my instruction patterns so tightly? https://owasp.org/www-community/controls/Bytecode_obfuscation From daniel.smith at oracle.com Wed Nov 4 18:18:02 2020 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 4 Nov 2020 11:18:02 -0700 Subject: EG meeting, 2020-11-04 In-Reply-To: References: Message-ID: > On Nov 3, 2020, at 4:53 PM, Dan Smith 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., Double., 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. From forax at univ-mlv.fr Thu Nov 5 09:42:01 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Nov 2020 10:42:01 +0100 (CET) Subject: EG meeting, 2020-11-04 In-Reply-To: References:

Message-ID: <1590296977.165600.1604569321170.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "daniel smith" > ?: "valhalla-spec-experts" > 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 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., >> Double., 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 ()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 (I)V can not be used as a super call. R?mi From brian.goetz at oracle.com Thu Nov 5 19:21:02 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 5 Nov 2020 14:21:02 -0500 Subject: EG meeting, 2020-11-04 In-Reply-To: References:

Message-ID: <01d02782-7756-22c9-293e-8ff62a0c7e98@oracle.com> Good points Dan! As to precedent, I am always leery of this, as indeed everything we do (or don't do) is frequently wishfully construed as a forever promise.? On the other hand, let's imagine where Java would be if we routinely provided source- and binary- migration tools when changing the platform.? Yes, there's a cost to maintaining and using those tools, but on the other hand, we'd be able to shed legacy more rapidly if there's a reasonable mitigation path (change/recompile your source code, run your jars through the Jar Grinder), and that reduces cost.? So I'm not sure the mere fact of _having_ a migration tool is a net loss; it's a complex set of tradeoffs.? But I think we can draw a defensible line here: these classes (like String) are effectively part of the _language_, not random runtime library classes. If there were a migration tool, I'd like it to work in both online (agent) and offline (jar rewriter) mode. I too am nervous about rewriting code with different semantics without the user opting in somehow (such as by specifying an agent or a command-line flag.) Here's another possibility: provide a "limp mode" fallback option that allows the JVM to interpret all classes as having identity semantics.? This would of course inhibit all Valhalla optimizations, and you'd have to select this mode if even one JAR on your classpath is old.? But at least it would still work.? And if you didn't like this, you could change your code or run your JARs through the grinder. On 11/5/2020 12:05 PM, Dan Heidinga wrote: > Thanks Dan for capturing the notes and leading the discussion. > > I want to highlight a couple of other concerns that were raised during > the call: > > * Precedent?? Are we setting a precedent by providing a tool to > address Valhalla migration compatibility?for old class files?? We > often talk about yesterday's solutions being today's problems and I > can see this coming back to bite us in two ways.? The first being that > we're effectively saying the JDK should provide migration tools for > removed / changed APIs which opens the door to every future removed > api requesting the same level of tooling support ("You did it for > Integer in Valhalla, why won't you do it for MY critical api > problem"). The second being the endless bikeshed discussions (now and > in the future) about the criteria required for the JDK to provide > compatibility based bytecode rewrites. > > * Support?? This is a "best effort" kind of tool that *changes the > meaning* of the program being modified.? In lots of cases, this won't > matter as the application never cared about the identity of the > Integer.? In others, it will matter and will lead to difficult to find > bugs.? Is a program that refuses to run better than a subtly wrong > one?? I'd argue yes even though it will anger a lot of users and > hinder migration. > > As an example the kinds of programs that can be affected by this, I > see the use of java.beans.PropertyChangeSupport in Spring's Spring-IDE > project where "new Integer" is being passed thru three layers of > subclasses to eventually call the firePropertyChange method [1] which > states "No event is fired if old and new values are equal and > non-null."? The code here (thankfully) doesn't depend on the identity > of the Integer but it easily could which would mean a listener > wouldn't be notified.? Changing it automatically would make it subtly > wrong.? These are the kinds of problems a tool can introduce and are > more likely to be a problem in larger applications. > > I'm leery of adding this kind of "best effort" tool to help migration > as the tool may lead to more problems than it solves. Long term, we > may be better off dealing with the painful migration due to > retcon'ing?Integer. > > --Dan > > [1] > https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/beans/PropertyChangeSupport.html#firePropertyChange(java.lang.String,java.lang.Object,java.lang.Object) > > > > On Wed, Nov 4, 2020 at 1:22 PM Dan Smith > wrote: > > > On Nov 3, 2020, at 4:53 PM, Dan Smith > 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., Double., 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. > From daniel.smith at oracle.com Wed Nov 18 15:58:32 2020 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 18 Nov 2020 08:58:32 -0700 Subject: EG meeting *canceled*, 2020-11-18 Message-ID: Nothing new in the list this time, so let's cancel. Next meeting December 2.