EG meeting, 2020-11-04

[Dan Heidinga]

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 <daniel.smith at oracle.com> wrote:

> > On Nov 3, 2020, at 4:53 PM, Dan Smith <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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20201105/c2a3c81c/attachment.htm>