Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

JDT Core/Plan/Java/13

Decisions for Java 13 • Support for preview features of earlier versions o Compiler Perspective  --enable-preview will be supported only for the current version of the compiler, which here is 13, meaning that you cannot expect a java 12 preview feature to be present in Java 13 See here for JDK behavior as well. https://bugs.eclipse.org/bugs/show_bug.cgi?id=544073#c32 o Dom Perspective  All Java 12 APIs that are supported will now throw an supportedOnlyInJava12Preview() exception. o UI Perspective  ?? o PDE Perspective  ??

Strategy from now on : To be discussed. Preview features are going to be the rule rather than exception from now on and this is a reality we need to accept and change accordingly. And hence what DOM exposes to the outside world (API) will change over the releases for preview features? From that perspective, there was a discussion (Sarika/Jay/Manoj). How do we handle these? I (Manoj) remember Markus pointing to a code which essentially say noreference so that a particular method is not considered as an API. /** * @nooverride This method is not intended to be re-implemented or extended by clients. * @noreference This method is not intended to be referenced by clients. */ This may be thought of for the “preview feature” methods. But what do we do for entire nodes, for example. Can we have a lesser API, APIs that have some reduced status as PreviewAPIs ? Who decides what an API is from Eclipse perspective? Shouldn’t PDE come into picture?

Back to the top