[Java] ClassCastException while discovering Apache math commons

[eclipse-modisco-bot]

| --- | --- | | Bugzilla Link | 351590 | | Status | ASSIGNED | | Importance | P5 normal | | Reported | Jul 08, 2011 11:06 EDT | | Modified | Aug 07, 2015 09:04 EDT | | Version | 0.9.0 | | Reporter | Nicolas Bros |

Description

Created attachment 199341\ stacktrace

When trying to discover the project math-commons from Apache (http://commons.apache.org/math/) with the Java discoverer, we get a ClassCastException, followed by a NPE, and no model is produced.\ (see attached stacktrace)

:notepad_spiral: stacktrace.txt

[eclipse-modisco-bot]

By Nicolas Bros on Jul 08, 2011 11:09

Created attachment 199342 math-commons configured as Eclipse Java project

:compression: math-commons.zip

[eclipse-modisco-bot]

By Gregoire Dupe on Jul 11, 2011 04:21

(In reply to comment #0)

no model is produced.

This bug is then "critical"

[eclipse-modisco-bot]

By Nicolas Bros on Aug 11, 2011 10:50

Created attachment 201318 (attachment deleted)\ patch

The discoverer does the ClassCastException when analyzing the value() invocation in:\ final Retry retry = method.getAnnotation(Retry.class); ...\ final int numRetries = retry.value();\ where "retry" is an annotation.

For MoDisco, the declaration corresponding to MethodInvocation "value()" is an AnnotationTypeMemberDeclaration, which is not a subtype of AbstractMethodDeclaration.

That's why the cast fails in JDTVisitor#endVisit(MethodInvocation).

This looks like an issue with the Java metamodel, that will have to be solved in the next major version (0.10), together with other necessary evolutions of the metamodel.

As for the second exception (NPE), it happens when building the signature of a method declaration (PolygonsSet#followLoop in math-commons) that has a parameter of type "final AVLTree.Node".\ MoDisco has not associated any type to this parameter, so it fails in MethodRedefinitionManager#getRawSignature when trying to access the type.

Here is a quick&dirty patch that works around the issues until they can be fixed in a better way.

[eclipse-modisco-bot]

By Fabien Giquel on Aug 11, 2011 13:11

ClassCastException and NPE are not related.\ I have created the bug 354532 for dealing with NPE. The current one will deal\ only with ClassCastException.

[eclipse-modisco-bot]

By Fabien Giquel on Aug 11, 2011 13:17

Nicolas, since i have separated in two bugs, i validate the part of the patch proposed on JDTVisitor.java (that is why i set review as "-" for the global patch)

The metamodel fix will not be done in Indigo SR1, so the work around proposed in the patch (JDTVisitor.java) must be commited for Indigo SR1 to minimize impact (discovery goes to the end).

For the other problem (NPE) see on the other bug 354532.

[eclipse-modisco-bot]

By Nicolas Bros on Aug 12, 2011 03:04

Created attachment 201369 patch for the ClassCastException

Here is a patch for the ClassCastException only.

:notepad_spiral: Bug 351590.patch

[eclipse-modisco-bot]

By Nicolas Bros on Aug 12, 2011 03:12

I have committed the patch in the trunk for SR1 (revision 4484).\ I'm leaving the bug open, because we still need to fix the metamodel in 0.10

[eclipse-modisco-bot]

By Gregoire Dupe on Sep 28, 2011 10:41

We have to focus on the move to EMF Facet. We may not have time enough to update the Java meta-model => P5

[eclipse-modisco-bot]

By Gregoire Dupe on Jun 01, 2012 11:27

(In reply to comment #5)

discovery goes to the end).

So not critical: back to normal.

[eclipse-modisco-bot]

By Fabien Giquel on Aug 06, 2015 03:44

Created attachment 255658 New CCE Test use case (474294 bugzilla)

:compression: testUseCase_474294.zip

[eclipse-modisco-bot]

By Fabien Giquel on Aug 06, 2015 03:47

The workaround patch from Nicolas Bros does not cover all use cases, and must be completed. I join a "new CCE Test use case.zip".

[eclipse-modisco-bot]

By Fabien Giquel on Aug 07, 2015 09:03

I propose some contribution for last use case, waiting for real Java metamodel evolution :

• no more error statut
• and one "UnresolvedMethod" instance is produced to identify the\ Annotation type member invoked.