RFR: 8263102: Expand documention of Method.isBridge
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods. Once the text is agreed to; I'll update the copyright year as well. ------------- Commit messages: - Fix trailing white space. - Rewording. - Update wording. - 8263102: Expand documention of Method.isBridg Changes: https://git.openjdk.java.net/jdk/pull/2852/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263102 Stats: 34 lines in 1 file changed: 30 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve linkage for isSynethetic. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2852/files - new: https://git.openjdk.java.net/jdk/pull/2852/files/35fd6b06..d3b7a3c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=00-01 Stats: 4 lines in 3 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Improve linkage for isSynethetic.
src/java.base/share/classes/java/lang/reflect/Method.java line 593:
591: * result. (While the Java language specification forbids a class 592: * declaring two methods with the same parameter types but a 593: * different return type, the virtual machine does not.)
I'm of two minds about this. This is certainly a good example of a bridge method. It doesn't motivate _why_ a bridge method is necessary in this case. It think it's because the language says you should be able to write code like EnumSet<E> es2 = es.clone(); so there needs to be a method defined in the class file whose return type is assignment-compatible with `EnumSet`. However, a `clone` method that returns `Object` is the only one that can override the `Object::clone` method. Thus, a something is necessary to span this gap -- a bridge method. On the other hand, this might be too much detail for here. This is a really obscure location. It seems like somewhere else would be better, and where a full explanation with examples can be provided. src/java.base/share/classes/java/lang/reflect/Method.java line 597:
595: * <p>Bridge methods may also be used by Java compiler in other 596: * circumstances to span across difference in Java Language 597: * semantics and JVM semantics.
If you decide to put less detail here, you could start with this statement. I think the main point is that there are some semantic gaps between methods in the Java language and in the JVM; bridge methods are necessary to "span" this gap. You might simply list some examples without explaining them fully. Would this be "used by **a** Java compiler" or "used by **the** Java compiler? ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 01:58:38 GMT, Stuart Marks <smarks@openjdk.org> wrote:
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Improve linkage for isSynethetic.
src/java.base/share/classes/java/lang/reflect/Method.java line 597:
595: * <p>Bridge methods may also be used by Java compiler in other 596: * circumstances to span across difference in Java Language 597: * semantics and JVM semantics.
If you decide to put less detail here, you could start with this statement. I think the main point is that there are some semantic gaps between methods in the Java language and in the JVM; bridge methods are necessary to "span" this gap. You might simply list some examples without explaining them fully.
Would this be "used by **a** Java compiler" or "used by **the** Java compiler?
Imo "created" should be better. Is there any case where a java compiler accepts bridge methods generated? ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
Hi Stuart, On 3/8/2021 6:02 PM, Stuart Marks wrote:
On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Improve linkage for isSynethetic. src/java.base/share/classes/java/lang/reflect/Method.java line 593:
591: * result. (While the Java language specification forbids a class 592: * declaring two methods with the same parameter types but a 593: * different return type, the virtual machine does not.) I'm of two minds about this. This is certainly a good example of a bridge method. It doesn't motivate _why_ a bridge method is necessary in this case. It think it's because the language says you should be able to write code like EnumSet<E> es2 = es.clone(); so there needs to be a method defined in the class file whose return type is assignment-compatible with `EnumSet`. However, a `clone` method that returns `Object` is the only one that can override the `Object::clone` method. Thus, a something is necessary to span this gap -- a bridge method.
On the other hand, this might be too much detail for here. This is a really obscure location. It seems like somewhere else would be better, and where a full explanation with examples can be provided.
If someone is looking at isBridge and wondering what it does, having some discussion there some reasonable :-) The text in question is not intended to be exhaustive and the exact use of bridge methods can, in principle, be Java compiler dependent. Also, if in the future there are new JVM/platform facilities added so that bridge methods are not necessarily required for the cases where they are now used, I intended to write this text so it would still be correct. Thanks, -Joe
On Fri, 5 Mar 2021 21:25:20 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
I suggest briefly mentioning generic specialization as an example as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2852/files - new: https://git.openjdk.java.net/jdk/pull/2852/files/d3b7a3c3..44552784 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=01-02 Stats: 20 lines in 1 file changed: 9 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Respond to review feedback.
src/java.base/share/classes/java/lang/reflect/Method.java line 589:
587: * different return type, the virtual machine does not. 588: * A 589: * common case where covariant overrides are used is for a {@link
I think the example should be clearer because here, you don't show the code of EnumSet.clone(). I wonder if it's not easier if all the code is visible interface I { Object m(); } class A implements I { String m() { return "hello"; } } so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object, the bridge method with this pseudo-code class A implements I { /* bridge */ Object m() { return m(); } // calls m()String String m() { return "hello"; } } ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 07:19:27 GMT, Rémi Forax <github.com+828220+forax@openjdk.org> wrote:
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Respond to review feedback.
src/java.base/share/classes/java/lang/reflect/Method.java line 589:
587: * different return type, the virtual machine does not. 588: * A 589: * common case where covariant overrides are used is for a {@link
I think the example should be clearer because here, you don't show the code of EnumSet.clone(). I wonder if it's not easier if all the code is visible interface I { Object m(); } class A implements I { String m() { return "hello"; } } so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object, the bridge method with this pseudo-code class A implements I { /* bridge */ Object m() { return m(); } // calls m()String String m() { return "hello"; } }
Hi Remi, Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy <darcy@openjdk.org> wrote:
src/java.base/share/classes/java/lang/reflect/Method.java line 589:
587: * different return type, the virtual machine does not. 588: * A 589: * common case where covariant overrides are used is for a {@link
I think the example should be clearer because here, you don't show the code of EnumSet.clone(). I wonder if it's not easier if all the code is visible interface I { Object m(); } class A implements I { String m() { return "hello"; } } so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object, the bridge method with this pseudo-code class A implements I { /* bridge */ Object m() { return m(); } // calls m()String String m() { return "hello"; } }
Hi Remi,
Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted.
The prose description here and is still rather clumsy, though. If you're going to use EnumSet.clone() as an example, maybe run with that and list the methods directly instead of saying "EnumSet.clone() returns EnumSet rather than Object", be more explicit. Maybe something like the following: The Object class has the method: clone()``` whereas the EnumSet class has this method: <E> clone()```
From the JVM's perspective, the second method doesn't override the first, because they have different return types. The Java compiler provides a proper override by inserting the following bridge method into the EnumSet class: clone()``` that simply calls the second method and returns its result.
------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On 3/9/2021 12:03 PM, Stuart Marks wrote:
On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy <darcy@openjdk.org> wrote:
src/java.base/share/classes/java/lang/reflect/Method.java line 589:
587: * different return type, the virtual machine does not. 588: * A 589: * common case where covariant overrides are used is for a {@link I think the example should be clearer because here, you don't show the code of EnumSet.clone(). I wonder if it's not easier if all the code is visible interface I { Object m(); } class A implements I { String m() { return "hello"; } } so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object, the bridge method with this pseudo-code class A implements I { /* bridge */ Object m() { return m(); } // calls m()String String m() { return "hello"; } } Hi Remi,
Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted. The prose description here and is still rather clumsy, though. If you're going to use EnumSet.clone() as an example, maybe run with that and list the methods directly instead of saying "EnumSet.clone() returns EnumSet rather than Object", be more explicit. Maybe something like the following:
The Object class has the method: clone()``` whereas the EnumSet class has this method: <E> clone()``` From the JVM's perspective, the second method doesn't override the first, because they have different return types. The Java compiler provides a proper override by inserting the following bridge method into the EnumSet class: clone()``` that simply calls the second method and returns its result.
Pushed a refinement along those lines; new text: A bridge method is a synthetic method created by a Java compiler alongside a method originating from the source code. Bridge methods are used by Java compilers in various circumstances to span differences in Java programming language semantics and JVM semantics. One example use of bridge methods is as technique for a Java compiler to support covariant overrides, where a subclass overrides a method and gives the new method a more specific return type than the method in the superclass. While the Java language specification forbids a class declaring two methods with the same parameter types but a different return type, the virtual machine does not. A common case where covariant overrides are used is for a Cloneable class where the clone method inherited from java.lang.Object is overridden and declared to return the type of the class. For example, Object declares protected Object clone() throws CloneNotSupportedException {...} and EnumSet<E> declares its language-level covariant override public EnumSet<E> clone() {...} If this technique was being used, the resulting class file for EnumSet would have two clone methods, one returning EnumSet<E> and the second a bridge method returning Object. The bridge method is a JVM-level override of Object.clone(). The body of the clone bridge method calls its non-bridge counterpart and returns its result. -Joe
On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy <darcy@openjdk.org> wrote:
src/java.base/share/classes/java/lang/reflect/Method.java line 589:
587: * different return type, the virtual machine does not. 588: * A 589: * common case where covariant overrides are used is for a {@link
I think the example should be clearer because here, you don't show the code of EnumSet.clone(). I wonder if it's not easier if all the code is visible interface I { Object m(); } class A implements I { String m() { return "hello"; } } so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object, the bridge method with this pseudo-code class A implements I { /* bridge */ Object m() { return m(); } // calls m()String String m() { return "hello"; } }
Hi Remi,
Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted.
@jddarcy, the problem i see is that `EnumSet` is not used a lot and `clone` has another layer of complexity because of CloneNotSupportedException, etc. So i'm not sure that using EnumSet.clone() is the right example here. Perhaps String.compareTo()/Comparable.compareTo() is a better example ? But generics are in the middle too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Respond to review feedback.
src/java.base/share/classes/java/lang/reflect/Method.java line 579:
577: * Bridge methods are used by Java compilers in various 578: * circumstances to span across differences in Java programming 579: * language semantics and JVM semantics.
Quibble: "span across" => "span" ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 19:51:42 GMT, Stuart Marks <smarks@openjdk.org> wrote:
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Respond to review feedback.
src/java.base/share/classes/java/lang/reflect/Method.java line 579:
577: * Bridge methods are used by Java compilers in various 578: * circumstances to span across differences in Java programming 579: * language semantics and JVM semantics.
Quibble: "span across" => "span"
Oh, also maybe need a <p> tag here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Respond to review feedback.
Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2852/files - new: https://git.openjdk.java.net/jdk/pull/2852/files/44552784..7c8397e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=02-03 Stats: 11 lines in 1 file changed: 3 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 22:35:19 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Respond to review feedback.
src/java.base/share/classes/java/lang/reflect/Method.java line 581:
579: * language semantics and JVM semantics. 580: * 581: * One example use of bridge methods is as technique for a
"a technique" ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo noted by bpb. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2852/files - new: https://git.openjdk.java.net/jdk/pull/2852/files/7c8397e4..0425a2f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
On Tue, 9 Mar 2021 23:38:26 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
Fix typo noted by bpb.
OK just a couple markup comments, otherwise good. src/java.base/share/classes/java/lang/reflect/Method.java line 597:
595: * and {@code EnumSet<E>} declares its language-level {@linkplain java.util.EnumSet#clone() covariant override}<br> 596: * {@code public EnumSet<E> clone() {...}}<br> 597: * If this technique was being used, the resulting class
Not sure what the preferred code block markup style is here; maybe `<pre>{@code ...}</pre>` instead of `<br>`. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2852
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback, reflow paragraphs, update copyrights. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2852/files - new: https://git.openjdk.java.net/jdk/pull/2852/files/0425a2f3..97c59502 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=04-05 Stats: 29 lines in 3 files changed: 0 ins; 1 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
On Fri, 5 Mar 2021 21:25:20 GMT, Joe Darcy <darcy@openjdk.org> wrote:
The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
Once the text is agreed to; I'll update the copyright year as well.
This pull request has now been integrated. Changeset: 67ea3bd6 Author: Joe Darcy <darcy@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/67ea3bd6 Stats: 42 lines in 3 files changed: 35 ins; 0 del; 7 mod 8263102: Expand documention of Method.isBridge Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/2852
participants (6)
-
Brian Burkhalter
-
Joe Darcy
-
Joe Darcy
-
liach
-
Rémi Forax
-
Stuart Marks