Open eclipse-viatra-bot opened 6 months ago
By Istvan Rath on Apr 01, 2013 05:11
A clarification: these special Java types can be assigned to attributes.
(In reply to comment #0)
Model elements of type Class<? extends something> result in a java.lang.Class
type in the generated evaluateXExpression() method instead of something meaningful. (E.g. "?" or the given type itself.) This causes faulty code (since "T cannot be resolved to a type"). In my particular case the model element is: Class<? extends Event> eventType. But the generated code looks like this: java.lang.Class
eventGuardType = (java.lang.Class )tuple.get(eventGuardTypePosition); Replacing the type parameter with the appropriate one solves the problem, of course. I.e. both -java.lang.Class<?> eventGuardType = (...), and -java.lang.Class<? extends Event> eventGuardType = (...) are OK.
If this is a reasonable behavior (i.e. because of a shortcoming of Xbase, or EMF, etc), it would be nice to mention it in the documentation, or perhaps a warning marker could be placed on the related element in the query.
By Zoltan Ujhelyi on Apr 01, 2013 12:00
As far as I remember, the Xbase model inferrer API allows putting generics information into the generated models, but in most cases we don't utilize that. This must be the source of the issue.
Istvan (David :) ), could you create some small example that reproduces this issue (just to make sure, we try to fix the correct issue :) ). Thanks.
By Istvan David on Apr 01, 2013 16:16
Sure thing; see the attached zip file (hu.bme.mit.incquery.cep.zip). It contains a plugin and a test plugin as a fragment for the former one.\ Steps to reproduce the issue:
As far as I can tell, the problem arises from the "EMFPatternLanguageJvmModelInferrerUtil.calculateType()" method. If you can give me some pointers I'll try to look into in on my own and submit a patch if succeeded.
(In reply to comment #2)
As far as I remember, the Xbase model inferrer API allows putting generics information into the generated models, but in most cases we don't utilize that. This must be the source of the issue.
Istvan (David :) ), could you create some small example that reproduces this issue (just to make sure, we try to fix the correct issue :) ). Thanks.
By Istvan David on Apr 01, 2013 16:17
Created attachment 229216 Example projects to reproduce issue #404652
:compression: hu.bme.mit.incquery.cep.zip
By Zoltan Ujhelyi on Apr 03, 2013 12:44
Thanks for the reproduction. I have taken a look and found out that there are two different problems we need to solve this issue 1) the TypeProvider interface does not handle EMF generics, the type it calculates does not contain the generics information 2) Additionally, your referred method indeed does not output the generics as required, so that needs to be changed as well.\ \ I have started working on the solution, but at this point, I found out we will need to change a large number of things inside the Type Provider to propagate this information, so I do not have a working solution yet.
By Istvan Rath on Apr 03, 2014 10:50
Assigning more complex issues to 0.8-M4. Please discuss if feasible or needs to be pushed to post-0.8.
By Istvan Rath on Apr 16, 2014 09:44
Postponing.
By Gabor Bergmann on May 28, 2014 12:45
These bugs will not be handled in this milestone
By Istvan Rath on Jun 04, 2014 10:45
Postponing to next development cycle.
By Istvan Rath on Sep 29, 2015 08:41
Pushing these issues to the 1.2 timeframe.
By Zoltan Ujhelyi on Mar 17, 2016 08:27
Replaced target milestone from incquery with VIATRA
By Zoltan Ujhelyi on Mar 17, 2016 08:47
Postponed tickets to 1.3
By Zoltan Ujhelyi on May 26, 2016 08:44
1.3 M1 already passed.
By Zoltan Ujhelyi on Jun 15, 2016 10:41
The new type inferrer from bug 437972 could be extended to also support generic EMF types, but that is not reasonable for 1.3, especially as we have to plan how to handle this case in the runtime (Rete and LS matchers as well).
By Zoltan Ujhelyi on Jan 25, 2017 07:45
Mass move of tickets we are not expecting to solve soon to the Future milestone.
By Zoltan Ujhelyi on Oct 04, 2017 05:26
Moving potential tasks from future to 2.0.
By Zoltan Ujhelyi on Feb 08, 2018 07:21
Postponing to a future release.
By Zoltan Ujhelyi on May 27, 2019 07:45
Postponing tickets to FUTURE until effort is allocated to fix them.
| --- | --- | | Bugzilla Link | 404652 | | Status | ASSIGNED | | Importance | P3 major | | Reported | Mar 31, 2013 21:59 EDT | | Modified | May 27, 2019 07:45 EDT | | Version | oldinquery | | Reporter | Istvan David |
Description
Model elements of type Class<? extends something> result in a java.lang.Class type in the generated evaluateXExpression() method instead of something meaningful. (E.g. "?" or the given type itself.) This causes faulty code (since "T cannot be resolved to a type").
In my particular case the model element is: Class<? extends Event> eventType.\ But the generated code looks like this:\ java.lang.Class eventGuardType = (java.lang.Class)tuple.get(eventGuardTypePosition);
Replacing the type parameter with the appropriate one solves the problem, of course. I.e. both\ -java.lang.Class<?> eventGuardType = (...), and\ -java.lang.Class<? extends Event> eventGuardType = (...)\ are OK.
If this is a reasonable behavior (i.e. because of a shortcoming of Xbase, or EMF, etc), it would be nice to mention it in the documentation, or perhaps a warning marker could be placed on the related element in the query.