Home » Modeling » TMF (Xtext) » How can I infer jvm type which has super type which is derived from part of domain model
| How can I infer jvm type which has super type which is derived from part of domain model [message #809201] |
Tue, 28 February 2012 15:43  |
|
I'm trying JVM language Tutorial.
This great article has some missing parts:
* Generated java classes have no super type notations.
* Until satisfy some build paths, closures described in example will not work
So I'm finding missing parts, and trying other experiments.
below code are part of type inferrer:
result.superTypes += element.superType.cloneWithProxies
element is an instance of Entity ( in JVM language Tutorial)
above code works fine when super type is one of normal java classes.
so below DSL was compiled well as I suspected:
entity A extends ArrayList{
}
but with java class which is generated by same xtext building context
(a class which is derived from Entity):
entity A{
}
entity B extends A{
}
It throws an error:
java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.eclipse.xtext.xbase.compiler.ImportManager.allowsSimpleName(ImportManager.java:93)
at org.eclipse.xtext.xbase.compiler.ImportManager.appendType(ImportManager.java:72)
at org.eclipse.xtext.xbase.compiler.StringBuilderBasedAppendable.appendType(StringBuilderBasedAppendable.java:101)
at org.eclipse.xtext.xbase.compiler.StringBuilderBasedAppendable.append(StringBuilderBasedAppendable.java:23)
at org.eclipse.xtext.xbase.compiler.TypeReferenceSerializer.serialize(TypeReferenceSerializer.java:115)
at org.eclipse.xtext.xbase.compiler.TypeReferenceSerializer.serialize(TypeReferenceSerializer.java:61)
at org.eclipse.xtext.xbase.compiler.TypeReferenceSerializer.serialize(TypeReferenceSerializer.java:58)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.serialize(JvmModelGenerator.java:1050)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateExtendsClause(JvmModelGenerator.java:376)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateBody(JvmModelGenerator.java:160)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateType(JvmModelGenerator.java:96)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._internalDoGenerate(JvmModelGenerator.java:87)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.internalDoGenerate(JvmModelGenerator.java:1105)
at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.doGenerate(JvmModelGenerator.java:76)
at org.eclipse.xtext.builder.BuilderParticipant.handleChangedContents(BuilderParticipant.java:222)
at org.eclipse.xtext.builder.BuilderParticipant.build(BuilderParticipant.java:168)
at org.eclipse.xtext.builder.impl.RegistryBuilderParticipant.build(RegistryBuilderParticipant.java:60)
at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:160)
at org.eclipse.xtext.builder.impl.XtextBuilder.incrementalBuild(XtextBuilder.java:141)
at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:91)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
At first, I thought it might be some problem with build dependency things.
But referencing types(derived form Entity model) as property(JvmField) seems fine.
I can't understand this difference.
Any help?
ps.
Generated java files are relatively hard to read, So I wanted to review xtend files(likes JvmTypeBuilder.xtend) which are delivered by plugin bundle rather than review derived java source file.
But because of french quotes and incorrect charset detection, So I had to see just broken source codes. And I couldn't find way to change charset.
of course, I can manually extract xtend files from jars, and I can see it with prefer charset, as you know, it's quite annoying. any suggestions?
[Updated on: Tue, 28 February 2012 15:48] Report message to a moderator |
|
| |
| Re: How can I infer jvm type which has super type which is derived from part of domain model [message #1003113 is a reply to message #1002869] |
Sun, 20 January 2013 09:17  |
|
On 01/19/2013 06:58 PM, Alan Alberghini wrote:
> Have you found a solution?
> I'm getting stuck with a (I guess) similar issue in my DSL where I'm
> trying to generate a Java interface + a Java support Class (implementing
> that same interface) for every entity in my model.
> I tried using both
>
> it.superTypes +=
> typeRefs.createTypeRef(typeRefs.findDeclaredType([interfaceName], entity))
>
> and
>
> it.superTypes += entity.newTypeRef([interfaceName])
>
> where entity is an Entity object from my model and [interfaceName] is
> the complete qualified name of the interface (which is "accepted"
> beforehand by the inferrer), but I keep getting null JvmTypeReferences
> from both methods.
> Do I need to explicitly "register" the interfaces/classes I'm generating
> before referring to them when setting the superTypes?
Hi
I cannot test it at the moment:
- when you use toClass in the inferrer you get a JvmGeneritType
- to create a type reference for the superTypes you can use newTypeRef
which accepts a JvmDeclaredType (and JvmGenericType is a JvmDeclaredType)
I don't think instead that using a qualified name would work in this
context... thus, instead of using interfaceName, use the actual
JvmGenericType that you inferred for the interface
hope this helps
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: How can I infer jvm type which has super type which is derived from part of domain model [message #1003126 is a reply to message #1003113] |
Sun, 20 January 2013 10:14 |
 Alan Alberghini
Messages: 19
Registered: January 2013 |
Junior Member |
|
|
Lorenzo Bettini wrote on Sun, 20 January 2013 10:17
Hi
I cannot test it at the moment:
- when you use toClass in the inferrer you get a JvmGeneritType
- to create a type reference for the superTypes you can use newTypeRef
which accepts a JvmDeclaredType (and JvmGenericType is a JvmDeclaredType)
I don't think instead that using a qualified name would work in this
context... thus, instead of using interfaceName, use the actual
JvmGenericType that you inferred for the interface
hope this helps
Lorenzo
Thanks for your answer.
Unfortunately, I cannot find a newTypeRef method which accepts a JvmDeclaredType as argument (I'm using Xtext 2.2.1), as it only accepts a Class or a String argument.
Using the qualified name of the JvmGenericType actually seems to almost work, but there's still something not quite right.
Will post any news as soon as I find a way to make it work...
EDIT:
The type references seem to be working now (will post a complete working example after the last issue is solved), but I keep getting a lot of errors while editing the (text) model file: it seems like the validator (the default one, because I didn't specify a custom one yet) is triggered every time a small change is done to the model, which will leave it in a non-consistent state most of the times (open braces, statements not terminated etc.).
What triggers this "aggressive" behavior of the validator? Is there a way to tell the validator to chill-out for a little while? 
EDIT2:
Found out the culprit: I just needed some more null-checking inside the inferrer to prevent inferring null-entities (created in the middle of editing).
Will post a complete example/tutorial for reference soon.
[Updated on: Mon, 21 January 2013 08:31] Report message to a moderator |
|
|
| Re: How can I infer jvm type which has super type which is derived from part of domain model [message #1004134 is a reply to message #1003126] |
Tue, 22 January 2013 16:21 |
|
On 01/20/2013 11:14 AM, Alan Alberghini wrote:
> Lorenzo Bettini wrote on Sun, 20 January 2013 10:17
>> Hi
>>
>> I cannot test it at the moment:
>>
>> - when you use toClass in the inferrer you get a JvmGeneritType
>> - to create a type reference for the superTypes you can use newTypeRef
>> which accepts a JvmDeclaredType (and JvmGenericType is a JvmDeclaredType)
>>
>> I don't think instead that using a qualified name would work in this
>> context... thus, instead of using interfaceName, use the actual
>> JvmGenericType that you inferred for the interface
>>
>> hope this helps
>> Lorenzo
>
> Thanks for your answer.
> Unfortunately, I cannot find a newTypeRef method which accepts a
> JvmDeclaredType as argument (I'm using Xtext 2.2.1), as it only accepts
> a Class or a String argument.
> Using the qualified name of the JvmGenericType actually seems to almost
> work, but there's still something not quite right.
> Will post any news as soon as I find a way to make it work...
>
>
I (and probably other people) would strongly suggest you to switch to
Xtext 2.3.1 where the inferrer and related classes are really much better :)
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| | | | | | | |
| Re: How can I infer jvm type which has super type which is derived from part of domain model [message #1053827 is a reply to message #1051432] |
Tue, 07 May 2013 18:47 |
|
On 04/28/2013 09:55 PM, Alan Alberghini wrote:
> Sorry for the long wait, Nils.
> My solution basically boils down to:
>
> generate all interfaces first with a dedicated inferrer
> generate all support classes after the interfaces are generated
>
> To link the support classes to the interfaces (in order to generate an
> "implements" declaration in the source code), one needs to add a
> JvmTypeReference to the "superTypes" list in the support class.
> This is the way I get the type reference:
> entity.eContainer.newTypeRef(String qualifiedName)
> Here I use the container of the entity as context and retrieve a type
> reference to the implemented interface (generated on the first infer
> pass) by passing its fully qualified name to the newTypeRef method.
> Should you use a more recent version of Xtext, as Lorenzo pointed out
> before, you could use a newTypeRef method accepting a JvmDeclaredType,
> like the one returned by the "toInterface" method.
> That's basically it. If you need further explanations with more code
> examples please tell me and I'll manage to add some more information.
>
as a follow-up, in case, once you inferred interfaces, you need to refer
to them when inferring the classes, and you did not keep track of them,
you can still retrieve the JvmDeclaredType by using
IJvmModelAssociations, and then create the type reference, e.g.,
@Inject extension TypeReferences
@Inject extension IJvmModelAssociations
def associatedInterfaceType(EObject t) {
t.jvmElements.filter(typeof(JvmGenericType)).
filter[interface].head
}
def associatedInterface(TJTraitExpression t) {
t.associatedInterfaceType?.createTypeRef()
}
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:11:25 GMT 2024
Powered by FUDForum. Page generated in 0.05402 seconds |
] 
Search
Help
Register
Login
Home
