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}


> 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