Hello, Could you please review the attached JEP?
Thanks, SAM
Title: BeanInfo Generation Improvements Author: Sergey Malenkov Organization: Oracle Created: 2014/4/1 Type: Feature State: Draft Exposure: Open Component: client/beans Scope: JDK RFE: 4763438, 4058433 Discussion: [email protected] Start: 2014/Q1 Effort: S Duration: S Template: 1.0 Reviewed-by: Endorsed-by: Funded-by: Oracle Client-libs Team Summary ------- Replace the @beaninfo tags, which are processed at compile-time to generate BeanInfo classes, with the corresponding annotations, which are used to generate BeanInfo at runtime. Motivation ---------- This work be done to make the modularization of the client library easier. It also simplifies the creation of the custom BeanInfo by users. Description ----------- Now all BeanInfo are automatically generated at runtime, but several Swing classes generates BeanInfo classes from the @beaninfo tags at compile-time. Here we propose to replace the @beaninfo tags with the following annotations and add some improvements to the existing introspection algorithm. public @interface Bean { String description() default ""; String defaultProperty() default ""; String defaultEventSet() default ""; } public @interface Property { boolean bound() default true; boolean expert() default false; boolean hidden() default false; boolean preferred() default false; boolean visualUpdate() default false; String description() default ""; String[] enumerationValues() default {}; } public @interface SwingContainer { boolean value() default true; String delegate() default ""; } These annotations will set the corresponding feature attributes during the BeanInfo generation at runtime. It will allow to remove automatically generated classes and prepare the client library for the modularization. Also, it will be useful for users to describe the BeanInfo in the class instead of creating a separate BeanInfo class for that bean class. Some feature attributes are described here: https://sites.google.com/site/malenkov/java/071004 Testing ------- Need to verify that the new introspection algorithm behaves as expected. Need to verify that the new introspection algorithm doesn't break backward compatibility in unexpected ways (or need to ensure that cases in which backward compatibility is not preserved are sufficiently rare). Risks and Assumptions --------------------- The primary risk of this change is that any change affecting introspection has the potential for backwards incompatibility. But we expect the the risk is very low. Dependences ----------- Now it is hard to prepare the client library for modularization. Impact ------ - Compatibility: The introspection of several properties may differ with new introspection algorithm, but we do not expect any backward incompatibility. - Security: We should do the security audit, because the reflection is used. - Performance/scalability: We do not expect the performance degradation. The refactoring of the introspection algorithm could improve the performance. - User experience: We should create an user guide about how to use new annotations instead of custom BeanInfo classes. - Documentation: The new annotations provide additional javadoc.
