Hi,

Can you provide the scenario so that we can try to reproduce?

Cheers, Doru

On 14 Feb 2012, at 15:31, Fabrizio Perin wrote:

Hi, did you try with the other extractor:

http://www.intooitus.com/products/infamix

the last verison seems much better then the previous I tried to use.

Cheers, Fabrizio

2012/2/14 Stéphane Ducasse stephane.ducasse@inria.fr can you send the mail to the moose-dev? Because I'm busy.

Stef

On Feb 14, 2012, at 2:01 PM, Holger Hans Peter Freyther wrote:

...

Hi Stephan,

I took a break from my GSM work and wrap up my studies (German Diploma is gone, it ends up only being a Bachelor..). I tried to import Saros[1] into moose and ended up with Exceptions on parsing catch statements. I have attached a file that shows this issue and the backtrace is below:

*** VerveineJ visitor got exception: 'fr.inria.verveine.core.gen.famix.Type cannot be cast to fr.inria.verveine.core.gen.famix.Class' while processing file: /home/ich/uni/bachelor-arbeit/dpp/de.fu_berlin.inf.dpp/src/de/fu_berlin/inf/dpp/Example.java java.lang.ClassCastException: fr.inria.verveine.core.gen.famix.Type cannot be cast to fr.inria.verveine.core.gen.famix.Class at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown Source) at org.eclipse.jdt.core.dom.CatchClause.accept0(CatchClause.java:162) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.TryStatement.accept0(TryStatement.java:258) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.IfStatement.accept0(IfStatement.java:190) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at fr.inria.verveine.extractor.java.FamixRequestor.acceptAST(Unknown Source) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1016) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:628) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:988) at fr.inria.verveine.extractor.java.VerveineJParser.parse(Unknown Source) at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown Source)

I have attached a workaround but I don't understand under which circumstances a type might not be resolvable to a Class (wrong classpath). Somehow the code already accepts a nil class, so adding the exception handling only makes the code more ugly but might end up being correct.

cheers holger

PS: What is the license of that code?

[1] http://www.saros-project.org/ <Example.java><workaround.diff>

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"What we can governs what we wish."

On 02/15/2012 07:25 AM, Tudor Girba wrote:

Hi,

Can you provide the scenario so that we can try to reproduce?

Yeah, the private mail stephane forwarded had these two attachments...

...

...

<Example.java><workaround.diff>

verveinej chokes when trying to resolve 'BackingStoreException' to a Class. I have attached the short example file and the local 'hack' I am using to get pass this issue.

holger

For information, we successfully corrected this bug in this specific case.

But it might not be always possible to have it always true (meaning the bug can reappear somewhere else)

The problem is one must think of verveineJ as a compiler, if one does not provide the accessed libraries, it misses information necessary to create correctly entities. This may result in verveineJ sometimes creating a Type when it should create a Class. Latter on, when the type is used somewhere else, we might require it to be a class and the bug would reappear.

In the general case, I don't think it is possible to avoid these bugs in all cases, so it is better to always give the needed libraries when using verveineJ.

nicolas

On Thursday 16 February 2012 09:53:41 Nicolas Anquetil wrote:

thanks

we will have a look at it.

thank you for reporting the issue and helping us to improve the tool

nicolas

On Wednesday 15 February 2012 09:25:22 Holger Hans Peter Freyther wrote:

...

On 02/15/2012 07:25 AM, Tudor Girba wrote:

...

Hi,

Can you provide the scenario so that we can try to reproduce?

Yeah, the private mail stephane forwarded had these two attachments...

...

...

...

<Example.java><workaround.diff>

verveinej chokes when trying to resolve 'BackingStoreException' to a Class. I have attached the short example file and the local 'hack' I am using to get pass this issue.

holger