-
Bug
-
Resolution: Fixed
-
P4
-
8u60
-
b89
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8142830 | emb-9 | Srikanth Adayapalam | P4 | Resolved | Fixed | team |
Please undo JDK-8037546. A synthetic method emitted for a lambda expression should NOT have a MethodParameters attribute, even when javac -parameters is specified.
(The reasoning comes from Brian Goetz: "We should make no promises whatsoever about reflection over synthetic members; these lambda methods are pure translation artifacts." That is, there is no compiler spec, so compiler transformations are NOT required to be fully and accurately visible through reflection. When a lambda expression is lowered to a method by javac, there is an obvious place to store parameter names, but if javac changes its translation strategy even a little -- which it's supposed to be allowed to do -- then any consumers relying on reflection over parameter names will break, setting off a wasteful round of bug filings and email exchanges. There are too many examples of consumers getting themselves into trouble by depending on something that works a particular way, even when it's specified that the way it works is unspecified! So, in the realm of metadata for synthetic methods, less is more.)
(The less-is-more maxim applies very strongly when the metadata generation is a compiler artifact in itself, i.e., the -parameters option peculiar to javac. The maxim applies somewhat less strongly when there's already a language-wide movement to preserve the metadata -- case in point is type annotations on explicitly declared lambda formals, where javac should continue to support reflection by emitting Runtime[In]VisibleTypeAnnotations attributes into the synthetic method emitted for a lambda expression.)
A likely related point is the transmission of _declaration_ annotations from (a) the declarations of variables which are subsequently captured by the lambda, to (b) the declarations of formal parameters of the synthetic method which represent/reify the captured variables. See http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009766.html. This transmission of declaration annotations should not happen -- after all, if an explicitly declared lambda formal has a declaration annotation, then the annotation is NOT transmitted to the corresponding formal parameter of the synthetic method. Furthermore, there should be no transmission of _type_ annotations from (a) the types appearing in declarations of variables which are subsequently captured by the lambda, to (b) the types of the declarations of formal parameters of the synthetic method which represent/reify the captured variables. The rationale here is that these formal parameters of the synthetic method are pure translation artifacts, so their types and type annotations must not become an attractive nuisance by appearing to correspond to captured variables in source.
(The reasoning comes from Brian Goetz: "We should make no promises whatsoever about reflection over synthetic members; these lambda methods are pure translation artifacts." That is, there is no compiler spec, so compiler transformations are NOT required to be fully and accurately visible through reflection. When a lambda expression is lowered to a method by javac, there is an obvious place to store parameter names, but if javac changes its translation strategy even a little -- which it's supposed to be allowed to do -- then any consumers relying on reflection over parameter names will break, setting off a wasteful round of bug filings and email exchanges. There are too many examples of consumers getting themselves into trouble by depending on something that works a particular way, even when it's specified that the way it works is unspecified! So, in the realm of metadata for synthetic methods, less is more.)
(The less-is-more maxim applies very strongly when the metadata generation is a compiler artifact in itself, i.e., the -parameters option peculiar to javac. The maxim applies somewhat less strongly when there's already a language-wide movement to preserve the metadata -- case in point is type annotations on explicitly declared lambda formals, where javac should continue to support reflection by emitting Runtime[In]VisibleTypeAnnotations attributes into the synthetic method emitted for a lambda expression.)
A likely related point is the transmission of _declaration_ annotations from (a) the declarations of variables which are subsequently captured by the lambda, to (b) the declarations of formal parameters of the synthetic method which represent/reify the captured variables. See http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009766.html. This transmission of declaration annotations should not happen -- after all, if an explicitly declared lambda formal has a declaration annotation, then the annotation is NOT transmitted to the corresponding formal parameter of the synthetic method. Furthermore, there should be no transmission of _type_ annotations from (a) the types appearing in declarations of variables which are subsequently captured by the lambda, to (b) the types of the declarations of formal parameters of the synthetic method which represent/reify the captured variables. The rationale here is that these formal parameters of the synthetic method are pure translation artifacts, so their types and type annotations must not become an attractive nuisance by appearing to correspond to captured variables in source.
- backported by
-
JDK-8142830 javac -parameters should not emit parameter names for lambda expressions
- Resolved
- relates to
-
JDK-8037546 javac -parameters does not emit parameter names for lambda expressions
- Closed
-
JDK-8138612 Do not retain declaration annotations on lambda formal parameters
- Closed