Re: EG meeting, 2020-11-04
- 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
Re: EG meeting, 2020-11-04
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.
>
>
Re: EG meeting, 2020-11-04
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 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., 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 t
