Community
Participate
Working Groups
Build Identifier: 20110916-0149 I am parsing sourcecode with the help of the ASTParser the following way: String source = ... ASTParser parser = ASTParser.newParser(AST.JLS3); parser.setKind(ASTParser.K_COMPILATION_UNIT); parser.setSource(source.toCharArray()); Up to Eclipse 3.7 this worked like a charme. Since the last update which introduced JLS4, the parser cannot parse a class it could before. When I open the AST in debugger mode, the scanner variable reports com.sun.jdi.InvocationException occurred invoking method. When I switch to JLS4, it parses the sourcecode without any problems and I get my compilation unit just as I did before with JLS3. Since I want my plugin to be used as well by people who haven't already switched to Eclipse 3.7.1, I cannot use JLS4 but would like to stay with JLS3. I should note, that no Exception is thrown at the console. The exception is only reported as value of the Scanner. I provide the class on which it fails (this does not happen for all classes) as well. Reproducible: Always Steps to Reproduce: 1. Update Eclipse 3.7 to 3.7.1 (Indigo Service Release 1) that brings JLS4 2. Parse source that worked with JLS3 again with JLS3 3. Get InvocationException message in scanner of AST
Created attachment 205923 [details] The source that cannot be parsed any more by JLS3 but is parsed by JLS4. The source that cannot be parsed any more by JLS3 but is parsed by JLS4.
Could you please provide the .log file of your workspace ?
Created attachment 205967 [details] Workspace log in case of using JLS3
Created attachment 205968 [details] Workspace log in case of using JLS4
The workspace logs did not reveal anything to me. By the way I noticed, that the Scanner object in the AST very often contains the "com.sun.jdi.InvocationException occurred invoking method" string, also when the class itself is parsed correctly, i.e. the CompilationUnit object created with compilationUnit = (CompilationUnit) parser.createAST(null); is shown as the parsed sourcecode in the debugger, while the attached source is shown as something like: !org.eclipse.jdt.core.dom.CompilationUnit@37423658 When using JLS4, it is shown as sourcecode in the debugger as well. Hope this helps.
(In reply to comment #5) > The workspace logs did not reveal anything to me. By the way I noticed, that > the Scanner object in the AST very often contains the > "com.sun.jdi.InvocationException occurred invoking method" string, This probably means that the debug print invocation of toString on the scanner object failed probably due to bad state. May be some field is null which would result in this message while viewing the object during debugging and could also indicate the underlying problem for the subject matter at hand.
I don't think the Scanner value is related to this particular problem, since it occurs as well with JLS4. Nevertheless, the source parsed with JLS4 is available as output of the CompilationUnit in debugger while not any more with JLS3. By the way .. when I walk through the AST of the CompilationUnit, I get the methods contained in the class. Very strange...
The same problem occurs with Eclipse 4 considering JLS3 and JLS4.
(In reply to comment #5) > The workspace logs did not reveal anything to me. By the way I noticed, that > the Scanner object in the AST very often contains the > "com.sun.jdi.InvocationException occurred invoking method" string, also when > the class itself is parsed correctly, i.e. the CompilationUnit object created > with It doesn't "contain" that string, as I said earlier the debug print toString method is encountering an NPE due the fact that scanner.source comes out to be null. You can expand the scanner object and you will be able to view the members. > When using JLS4, it is shown as sourcecode in the debugger as well. I see the same behavior here too, i.e the com.sun.jdi* message shows up when you view the value of the scanner object in the debugger even in JLS4 using HEAD version. Will continue to investigate.
Just so we are on the same page, can you paste a larger fragment of the code that you are stepping through and indicating where exactly you attempt to view the scanner object. Once I have this, I'll study the behavior difference between pre-JLS4 days and now to see what brought about this behavior. It is not clear to me (yet) that there is a bug here. You are peeking at internal state of objects while debugging and that visualization operation is failing due to partially cooked state of objects. I agree if things can be restored to the earlier state that enabled debugging then that would be better. (In reply to comment #0) > Up to Eclipse 3.7 this worked like a charme. Since the last update which > introduced JLS4, the parser cannot parse a class it could before. When I open > the AST in debugger mode, the scanner variable reports > > com.sun.jdi.InvocationException occurred invoking method. Do you have some clearer evidence that "the parser could not parse a class it could before" other than this debug print failure. May be if you paste the larger snippet you are stepping through and indicate clearly where you are able print the scanner object that you aren't anymore able to, I can follow up - Thanks.
> Do you have some clearer evidence that "the parser could not parse a class > it could before" other than this debug print failure. > > May be if you paste the larger snippet you are stepping through and indicate > clearly where you are able print the scanner object that you aren't anymore > able to, I can follow up - Thanks. Hello! Well -- the main failure for me was not the debug print failure (earlier I just thought it may indicate the problem's source), but that if I create the compilationUnit = (CompilationUnit) parser.createAST(null); and then take a type from it with BodyDeclaration t = compilationUnit.types().get(0); the execution of t.toString(); normally returned the source of the BodyDeclaration object as a string. Since JLS4 is in, with JLS3 it sometimes returns sth. like "!org.eclipse.jdt.core.dom.CompilationUnit@37423658" instead of the sourcecode. If I use JLS4, the same code returns me the sourcecode of the declaration as JLS3 did before. This happens e.g. with the earlier attached java file.
Created attachment 206392 [details] Contains an example Eclipse project that demonstrates the problem. This example project demonstrates the problem on the attached source code. With JLS3 it shows only an object-referece string, while JLS4 shows the source.
(In reply to comment #11) > Well -- the main failure for me was not the debug print failure (earlier I just > thought it may indicate the problem's source), but that if I create the I see, I understand better now, (In reply to comment #12) > Created attachment 206392 [details] > Contains an example Eclipse project that demonstrates the problem. Excellent, thanks, I'll see what is going on here.
org.eclipse.jdt.core.dom.TryStatement.resources() reads: public List resources() { // more efficient than just calling unsupportedIn2_3() to check if (this.resources == null) { unsupportedIn2_3(); } return this.resources; } I think this should be: public List resources() { // more efficient than just calling unsupportedIn2_3() to check if (this.resources != null) { unsupportedIn2_3(); } return this.resources; }
All cients of org.eclipse.jdt.internal.core.dom.NaiveASTFlattener are prone to this bug, which at the moment is fortunately all of org.eclipse.jdt.core.dom.ASTNode.toString() :) Minimal test case that shows the problem: public class X { X(){ try { } finally { } } } Patch will follow shortly. If the one character fix stands scrutiny will backport to 3.7.2 also.
Created attachment 206781 [details] Patch under test
(In reply to comment #11) > > Do you have some clearer evidence that "the parser could not parse a class > > it could before" other than this debug print failure. > > > > May be if you paste the larger snippet you are stepping through and indicate > > clearly where you are able print the scanner object that you aren't anymore > > able to, I can follow up - Thanks. > > Hello! > > Well -- the main failure for me was not the debug print failure (earlier I just > thought it may indicate the problem's source), but that if I create the > > compilationUnit = (CompilationUnit) parser.createAST(null); Hello, the patch posted fixes this problem which you identify as the main failure for you. For the inability to view the scanner object, as requested in comment# 10 please provide a snippet and also identify precisely where you view the value of the scanner object. Do you notice a difference between JLS3 and JLS4 in this exercise ? Do you notice a regression compared to earlier versions ? I am not sure yet there is a problem there. toString() methods are not always coded defensively, so if they run into an NPE, you will see the com.sun.jdi.InvocationException.
Released for 3.8 M4 via commits: 8ab95da8a0ea0d6e3c8c0619022e89253da6eb42 and 45bb778e6ee242f361e8397463f6e1b0b9b9dfa0 (the latter removing a sysout needlessly left in) If you still suspect the com.sun.jdi.InvocationException issue is real problem/ regression, please open a separate bug with clear steps - Thanks.
(In reply to comment #18) > Released for 3.8 M4 via commits: 8ab95da8a0ea0d6e3c8c0619022e89253da6eb42 and > 45bb778e6ee242f361e8397463f6e1b0b9b9dfa0 (the latter removing a sysout > needlessly > left in) > > If you still suspect the com.sun.jdi.InvocationException issue is real problem/ > regression, please open a separate bug with clear steps - Thanks. I don't think the InvocationException issue is a real problem; as I said, it was just a first suspect but obviously not the one responsible. Thank you for investigating the bug and fixing it. Cheers!
As the fix is a single character change that fixes a blatantly wrong piece of code, I have also arranged to release this into 3.7.2 and 3.6.2+java7 branches.
(In reply to comment #20) > As the fix is a single character change that fixes a blatantly wrong > piece of code, I have also arranged to release this into 3.7.2 and 3.6.2+java7 > branches. +1.
I found some more incorrect code which shouldn't impact any functionality. However, I have opened another bug 365582 to track the incorrect code.
Verified for 3.8M4 using build I20111202-0800
Verified for 3.7.2RC2 using build M20120118-0800
(In reply to comment #14) > org.eclipse.jdt.core.dom.TryStatement.resources() reads: > > public List resources() { > // more efficient than just calling unsupportedIn2_3() to check > if (this.resources == null) { > unsupportedIn2_3(); > } > return this.resources; > } This is actually fine. resources is null only if the ast level is 2 or 3 as this is initialized in the constructor for ast level >= 4. The real problem is that the resources() call is not within the if that checks for the jls level being >= JLS4 in the naive flattener as Satyam mentioned in bug 365582.
(In reply to comment #25) > This is actually fine. resources is null only if the ast level is 2 or 3 as > this is initialized in the constructor for ast level >= 4. > The real problem is that the resources() call is not within the if that checks > for the jls level being >= JLS4 in the naive flattener as Satyam mentioned in > bug 365582. You are right of course, we'll adopt the fix for bug 365582 at M6 time. Thanks Olivier.
(In reply to comment #26) > You are right of course, we'll adopt the fix for bug 365582 at M6 time. I meant M5 time.
(In reply to comment #27) > (In reply to comment #26) > > > You are right of course, we'll adopt the fix for bug 365582 at M6 time. > > I meant M5 time. Released the proper fix for M5. (In reply to comment #25) > This is actually fine. resources is null only if the ast level is 2 or 3 as > this is initialized in the constructor for ast level >= 4. Yes, indeed, I was led astray by the hang over memory of the compiler AST having resources set to valid ones even in (ill formed) Java 6 programs. For the maintenance streams, I'll leave things as they are as the probability of this situation acting up are very low, realistically speaking.
