JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method
David Holmes
David.Holmes at oracle.com
Fri Jul 15 05:49:30 UTC 2011
Hi Joe,
On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote:
> Please code review my JDK 8 changes for
>
> 7007535: (reflect) Please generalize Constructor and Method
> http://cr.openjdk.java.net/~darcy/7007535.3
>
> To summarize the changes, a new superclass is defined to capture the common
> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor.
> That superclass is named "Executable" along the lines of
> javax.lang.model.ExecutableElement, which models constructors and methods in
> the JSR 269 language model.
>
> Both specification and implementation code are shared. To preserve the right
> @since behavior, it is common that in Method/Constructor the javadoc for a
> method will now look like:
>
> /**
> * {@inheritDoc}
> * @since 1.5
> */
Unless they have fixed/changed javadoc (entirely possible) it used to be
that the above would not cause @throws declarations for unchecked exceptions
to be inherited - you have/had to explicitly repeat them as:
@throws <exception-type> {@inheritDoc}
Cheers,
David
-----
> Since Executable is being created in JDK 8, it would be incorrect for
> methods in that class to have an @since of 1.5; adding the @since in
> Method/Constructor preserves the right information.
>
> It would have been natural to also move common fields to Executable;
> however, HotSpot treats the Constructor and Method type specially and relies
> on the existing field ordering. Since altering the field layout would
> require coordinated HotSpot changes, I'm opting to not perform such a change
> right now. At least one abstract accessor method is declared in Executable
> to still allow code sharing even though the required field is not present.
> In other cases, package private instance methods on Executable are passed
> the needed state from overridden public methods in Method/Constructor.
>
> All java/lang/reflect regression tests pass on a full build with these changes.
>
> Thanks,
>
> -Joe
More information about the core-libs-dev
mailing list