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