EG meeting, 2020-11-04

[Brian Goetz]

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