A peek at the roadmap for pattern matching and more

[Eddie Aftandilian]

On Fri, Aug 14, 2020 at 10:43 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > Aside: My understanding of the MethodParameters attribute is that it's
> > intended more as an informational than API and unlikely to affect
> > application behaviour at runtime.
>
> The existing MP attribute represents a somewhat unfortunate compromise.
>
> The EE folks (remember EE?) had a compelling-enough use case for being
> able to reflect over parameter names, which was that they wanted to
> generate various remote-invocation stubs (corba, *RPC, etc) from
> classes, but felt that having to annotate each parameter
> (`foo(@MyNameIs("bob") String bob)`) would suck.  So they wanted us to
> reify the parameter names by default in the classfile, for reflection to
> serve up.
>
> The ME folks (remember ME?) freaked out; "Whoa, more bytes in the
> classfile, you have to make that optional, and not the default!"
>
> The EE guys came back with "OK, how about driving retention based on an
> annotation."
>
> We said (for the zillion'th time):  You know that's not what annotations
> are for.
>
> So the compromise was to make it a tooling option; invoke `javac` with
> `-parameters`.   Result: no one can count on them.
>
> Now, the MP attribute itself should not need to change here; only the
> conditions under which the language promises to make these available for
> reflection and condition the compatibility rules.
> > Making names significant and part of the API will affect refactoring
> > and separate compilation: developers are used to being able to freely
> > rename parameters without worrying about affects on other parts of
> > their code base or about breaking their consumers (library authors).
> >  Are there things the language can do to help with name transitions?
> >  Is treating parameter name changes in a __byname method as a breaking
> > API change something that developers will have to adapt to?
>
> Note that we already have this problem with records; the name of a
> component in records flows into constructor descriptors, accessor names,
> etc.  It is an open question whether the developers can handle the
> responsibility :)
>
> I have long wanted to have widely available, easy to use tooling that
> could detect incompatible changes between versions of a module, where it
> would look at the old bytecode and say "whoa, you did <incompatible
> thing> there, did you mean to?"  In the presence of such tooling, this
> would be one more set of assertions for such a mechanism.  But so far I
> haven't gotten my wish.  (Perhaps our IDE friends are cooking something
> like this up?)  I do think that detection of incompatible changes is
> something for tooling to handle, not the language.  But I agree that
> this is a concern, and more so than for records, which have the
> component names stapled to their forehead.
>

Inside Google we have enabled the `-parameters` attribute by default and
have an Error Prone check that simulates named parameters (
https://errorprone.info/bugpattern/ParameterName).

Initially we had it enabled as a compilation error.  We believed that
renames of parameters happened infrequently and rarely crossed compilation
boundaries.  We found that those renames were more frequent than expected,
and there were a number of accidental breaking changes to core libraries
like Guava that caused breakage at a distance.  We ended up demoting the
check to a warning.  The general feeling was that this was mostly a problem
for core libraries and not typical application code.  One proposal was to
leave it as an error by default, but to allow core libraries to opt out of
publishing their parameter names.

All that said, I don't think this is a problem for records since the names
there are clearly part of the API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200814/d1007517/attachment-0001.htm>