[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] parser question
|
Hi Martin,
since you need bindings, the internal Parser wouldn't suffice for your case.
You'd need almost all internal classes of the compiler, and you'd have to
interact with internal AST and internal bindings instead of the public DOM
varieties. Not a good idea.
The gap from ASTParser may be fairly small: where it calls into the
CompilationUnitResolver see that this guy is a subclass of Compiler.
Then two steps further inside (process(..)) one simply needs to suppress
unit.generateCode().
Unless I'm missing s.t., little should be standing in the way of an API
enhancement. Even less with a proposed patch :p
Obviously, measurement data also help promoting a performance feature.
Stephan
On 10.03.19 20:24, Martin Lippert wrote:
Hey Stephan,
I don’t need errors and warnings, the resolved AST is enough... :-)
And I would be fine with using the internal API directly, don’t really need any additional API guarantees or compatibility. The only missing piece of the puzzle for me is a simple example how to use the interval parser to generate the AST for me (after feeding the API with jars for the classpath and source files to parse, much like I do with ASTParser.parse...).
Any advice?
Cheers,
Martin
P.S.: adding an option to avoid code generation on the existing API would be fine, if course, too
Am 10.03.2019 um 19:17 schrieb Stephan Herrmann <stephan.herrmann@xxxxxxxxx>:
Hi Martin,
Do you need errors and warnings to be reported?
Reason for asking: some problems are detected as late as during code generation.
If you don't need those problems, it should theoretically be possible to skip code generation, but this option exists only in internal API. If you need this option exposed in public API and if you have numbers confirming that time is unnecessarily burnt during code gen, the an enhancement request in bugzilla could make sense.
Stephan
PS:
I found this:
org.eclipse.jdt.internal.compiler.parser.Parser
but I have no idea how to use that or how to configure that to generate an AST from source files.
You probably saw the word "internal" in the package name? :)
That's exactly what org.eclipse.jdt.core.dom.* encapsulates.
On 08.03.19 21:12, Martin Lippert wrote:
Hey!
I need to create ASTs (incl. type resolving) for Java source files (outside of an Eclipse project environment, just plain Java and some source files).
At the moment I am using:
ASTParser parser = ASTParser.newParser(AST.JLS11);
This works nicely, but I need to get ASTs for method bodies, so I configured the parser to NOT ignore method bodies. But this causes the parser to somehow call out to a compiler to generate bytecode - which I don’t need at all for my purpose. I am interested in the resolved AST only, no byte code necessary. Since this piece of the code is extremely sensitive to performance and memory footprint issues, I am looking into this.
Is there an alternative to this approach to avoid the bytecode generation?
I found this:
org.eclipse.jdt.internal.compiler.parser.Parser
but I have no idea how to use that or how to configure that to generate an AST from source files.
Can you shed some light on this? Any examples how to re-use this parser for generating ASTs (without bytecode generation)?
Thanks so much for your help!
-Martin
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev