On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <da...@openjdk.org> wrote:
> When new language features are added, the javax.lang.model may need to be > updated. For certain classes of features, the API update includes introducing > a new set of concrete visitors to handle the language feature. > > The API scaffolding to support the new feature tends to be considerably > larger than the API specifically for the new feature. > > To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) > and anticipated in the future, I think it would be helpful to introduce a > persistent set of preview visitors independent of any particular language > change. > When new language features are added, the javax.lang.model may need to be > updated. For certain classes of features, the API update includes introducing > a new set of concrete visitors to handle the language feature. > > The API scaffolding to support the new feature tends to be considerably > larger than the API specifically for the new feature. > > To aid work in progress (such as #18509) and anticipated in the future, I > think it would be helpful to introduce a persistent set of preview visitors > independent of any particular language change. When one of the preview visitors is subclassed, javac emits a warning like: javac VisitorTest.java VisitorTest.java:2: warning: [preview] ElementKindVisitorPreview is a reflective preview API and may be removed in a future release. public class VisitorTest extends javax.lang.model.util.ElementKindVisitorPreview { ^ 1 warning Once these preview visitors are present, the particular API to support language change P can be added and reviewed without being dwarfed in the overall scaffolding. The anticipated usage would be: Methods particular to supporting preview feature P can be annotated accordingly to indicate that usage. When P goes to a final feature, a new set of JDK $N visitors would be inserted between to latest numbered set of visitors and the preview visitors. Methods particular to P would be moved up into the new JDK $N visitors. For example, if feature P when final in JDK 25, there would be a new set of JDK 25 concrete visitors extended the existing JDK 14 visitors and superclass of the preview visitors would be changed from the JDK 14 visitor to the corresponding JDK 25 visitor. Methods associated with feature P would be moved up from the preview visitors into the JDK 25 visitors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2035521547
