Community
Participate
Working Groups
When I attempt to parse a piece of syntactically correct Java 1.5 text that contains an annotation, the resulting CompilationUnit contains a problem. This is the source I am trying to parse: @Init class X { int y; } Here is the code snippet I am running: ASTParser parser = ASTParser.newParser(AST.JLS3); parser.setSource("@Init class X { int y; }".toCharArray()); parser.setKind(ASTParser.K_COMPILATION_UNIT); CompilationUnit rootAST = (CompilationUnit) parser.createAST(null); System.out.println(rootAST.getProblems()[0]); The output is: Pb(596) Syntax error, annotations are only available if source level is 5.0 As far as I know, there should be no errors outputted. I am using 3.1 RC1 on Windows XP. thanks, --andrew eisenberg
You need to specify what compiler options the parser should use. Jim, should this case be handled with an IllegalStateException?
I apologize. I did not understand how compiler options work. I assumed that the compiler options were set to 1.5 by default since that is the target jre and it is the default of my workspace. I do not think this is a bug at all. The sample is now working. I added this in a static initializer in the class: private final static Hashtable<String, String> options = JavaCore.getOptions(); { options.put(JavaCore.COMPILER_COMPLIANCE, "1.5"); options.put(JavaCore.COMPILER_SOURCE, "1.5"); options.put("org.eclipse.jdt.core.compiler.source", "1.5"); options.put("org.eclipse.jdt.core.compiler.codegen.targetPlatform", "1.5"); } Then I added the line: parser.setCompilerOptions(options); directly before the setting the source of the parser. This seems to work. Thanks for your help. --andrew eisenberg I apologize. I did not understand how compiler options work. I assumed that the compiler options were set to 1.5 by default since that is the target jre and it is the default of my workspace. I do not think this is a bug at all. The sample is now working. I added this in a static initializer in the class: private final static Hashtable<String, String> options = JavaCore.getOptions(); { options.put(JavaCore.COMPILER_COMPLIANCE, "1.5"); options.put(JavaCore.COMPILER_SOURCE, "1.5"); options.put("org.eclipse.jdt.core.compiler.source", "1.5"); options.put("org.eclipse.jdt.core.compiler.codegen.targetPlatform", "1.5"); } Then I added the line: parser.setCompilerOptions(options); directly before the setting the source of the parser. This seems to work. Thanks for your help. --andrew eisenberg I apologize. I did not understand how compiler options work. I assumed that the compiler options were set to 1.5 by default since that is the target jre and it is the default of my workspace. I do not think this is a bug at all. The sample is now working. I added this in a static initializer in the class: private final static Hashtable<String, String> options = JavaCore.getOptions(); { options.put(JavaCore.COMPILER_COMPLIANCE, "1.5"); options.put(JavaCore.COMPILER_SOURCE, "1.5"); options.put("org.eclipse.jdt.core.compiler.source", "1.5"); options.put("org.eclipse.jdt.core.compiler.codegen.targetPlatform", "1.5"); } Then I added the line: parser.setCompilerOptions(options); directly before the setting the source of the parser. This seems to work. Thanks for your help. --andrew eisenberg
The implementation is behaving as spec'd. However, this PR points out a 'gotcha' of relying on default compiler options (or even project-specific ones). The following doc comment changes point out the problem to clients (neither the API nor implementation require changing). /** * Sets the compiler options to be used when parsing. * <p> * Note that {@link #setSource(IClassFile)}, * {@link #setSource(ICompilationUnit)}, * and {@link #setProject(IJavaProject)} reset the compiler options * based on the Java project. In other cases, compiler options default * to {@link JavaCore#getOptions()}. In either case, and especially * in the latter, the caller should carefully weight the consequences of * allowing compiler options to be defaulted as opposed to being * explicitly specified for the <code>ASTParser</code> instance. * For instance, there is a compiler option called "Source Compatibility Mode" * which determines which JDK level the source code is expected to meet. * If you specify "1.4", then "assert" is treated as a keyword and disallowed * as an identifier; if you specify "1.3", then "assert" is allowed as an * identifier. So this particular setting has a major bearing on what is * considered syntactically legal. By explicitly specifying the setting, * the client control exactly how the parser works. On the other hand, * allowing default settings means the parsing behaves like other JDT tools. * </p> * * @param options the table of options (key type: <code>String</code>; * value type: <code>String</code>), or <code>null</code> * to set it back to the default */ public void setCompilerOptions(Map options) /** * Sets the Java project used when resolving bindings. * This method automatically sets the compiler * options based on the given project: * <pre> * setCompilerOptions(project.getOptions(true)); * </pre> * See {@link #setCompilerOptions(Map)} for a discussion of * the pros and cons of using these options vs specifying * compiler options explicitly. * This setting is used in conjunction with <code>setSource(char[])</code>. * For the purposes of resolving bindings, types declared in the * source string will hide types by the same name available * through the classpath of the given project. * Defaults to none (<code>null</code>). * * @param project the Java project used to resolve names, or * <code>null</code> if none */ public void setProject(IJavaProject project) { Olivier, Could you commit these changes and close. Thanks.
New doc fixed and released in HEAD.
Verified for 3.1 RC2 using build N20050608-0010
Verified for 3.1 RC2 using build I20050610-0010
