Community
Participate
Working Groups
Once JLS3 APIs are fully operational in 3.1 stream: (1) Deprecate all JLS2-related APIs. Places in JDT Core are marked with TODOs like: // TODO (jeem) When JLS3 support is complete (post 3.0) - deprecated Clients should port their code to use the new JLS3 API and call {@link #newAST(int)} instead of using this constructor. (2) Remove notes on JDT Core API instructing people to avoid using JLS3. E.g. * <p> * <b>NOTE:</b>In Eclipse 3.0, there is no underlying parser support for * JLS3 ASTs. This support is planned for the follow-on release of * Eclipse which includes support for J2SE 1.5. Without a parser to create * JLS3 ASTs, they are not much use. Use JLS2 ASTs instead. * </p>
Jim, can we consider JLS3 as fully operational now?
Philippe, Are we ready to do this?
Created attachment 18782 [details] Patch to deprecate JLS2 in DOM/AST Olivier, Please review and release this patch which deprecates the JLS2-specific DOM/AST API and cleans up the specs. Notes: - All JLS2-only methods have been deprecated. - I did *not* deprecate the various FOO_PROPERTY constants for JLS2 only properties. This allows generic tools (like ASTRewrite) to use them properties without getting deprecations warnings. - All JLS3 constructs are now listed as @since 3.1 (even though most were introduced in 3.0 in an early form). This is consistent with 3.1 being the first release in which JLS3 is supported. - I introduced various internal methods in DOM/AST to get rid of deprecations. - SortElementBuild is the last remaining uses in JDT Core of JLS2. Someone should look at porting it to JLS3.
I will look at the SortElementBuilder in the same time I fix bug 81797 and bug 80036.
Fixed and released in HEAD.
Verified in I20050331-1600