| Separating JVM model and its implementation [message #1442762] |
Sat, 11 October 2014 16:37  |
 Owen Arden
Messages: 3
Registered: October 2014 |
Junior Member |
|
|
Hi,
First off, I'm really impressed with Xtext. I've always wanted to build Eclipse support for languages I've worked on and this is the first time I've managed to get any traction.
One thing that often comes up is the need to represent classes abstractly at the source level but generate an implementation that differs from it. Xtend does this to some degree with dispatch methods.
Unfortunately, I need something a little more drastic than Xtend. I'm working on a language for computing with persistent objects based on Fabric (www.cs.cornell.edu/projects/fabric/). There, we represent persistent objects as normal classes to the developer, but generate (for each class) an interface and two classes (a proxy class and an actual implementation).
I've subclassed JvmModelGenerator to output the translated classes, and all of this mostly works well within one project. However, I haven't found an effective method for recovering an appropriate model type from the compiled class files.
In the Polyglot compiler (www.cs.cornell.edu/projects/polyglot/), we serialize a type object into a field of the generated class. I've initially tried to replicate that by generating an XMI file for the model object and encoding it as a field in the output type. Then using a custom IJvmTypeProvider, I look for the field and deserialize the object.
This ends up generating several confusing errors that I've yet to understand. Before going into detail about those errors, I was hoping to have someone weigh in on whether the XMI route is really an appropriate one.
Is it reasonable to try to use XMI in this way? Is there another option? I'd like to avoid having to "invert" the JvmModelGenerator translation if possible -- i.e. create the Jvm types directly by interpreting the translated classes.
Thanks!
Owen
|
|
|
| Re: Separating JVM model and its implementation [message #1444123 is a reply to message #1442762] |
Mon, 13 October 2014 17:19  |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Owen,
please find my answers inline.
Am 11.10.14 21:10, schrieb Owen Arden:
> Hi,
> First off, I'm really impressed with Xtext. I've always wanted to build
> Eclipse support for languages I've worked on and this is the first time
> I've managed to get any traction.
Thanks!
> One thing that often comes up is the need to represent classes
> abstractly at the source level but generate an implementation that
> differs from it. Xtend does this to some degree with dispatch methods.
Active annotations take this to another level.
Key is, that the in-memory prepresentation knows about the class as it
would look like in its compiled form. That's what the JVM model is used for.
>
> Unfortunately, I need something a little more drastic than Xtend. I'm
> working on a language for computing with persistent objects based on
> Fabric (www.cs.cornell.edu/projects/fabric/). There, we represent
> persistent objects as normal classes to the developer, but generate (for
> each class) an interface and two classes (a proxy class and an actual
> implementation).
So far so good. Sounds like a model inferrer to me, that derives the
proxy and the implementation from the source AST.
> I've subclassed JvmModelGenerator to output the translated classes, and
> all of this mostly works well within one project.
That's not what I would expect from what you described. The model
inferer should know about the structure. There you'd also set the body
for methods etc so *usually* there is no need to customize the model
generator.
> However, I haven't
> found an effective method for recovering an appropriate model type from
> the compiled class files.
That would have been adressed implicitely if the model inferrer would
have been used.
> In the Polyglot compiler (www.cs.cornell.edu/projects/polyglot/), we
> serialize a type object into a field of the generated class. I've
> initially tried to replicate that by generating an XMI file for the
> model object and encoding it as a field in the output type. Then using
> a custom IJvmTypeProvider, I look for the field and deserialize the object.
> This ends up generating several confusing errors that I've yet to
> understand. Before going into detail about those errors, I was hoping
> to have someone weigh in on whether the XMI route is really an
> appropriate one.
Doesn't sound promising.
> Is it reasonable to try to use XMI in this way? Is there another
> option? I'd like to avoid having to "invert" the JvmModelGenerator
> translation if possible -- i.e. create the Jvm types directly by
> interpreting the translated classes.
I know that I'm repeating myself, but the inferrer would be the right
place to do that.
Best,
Sebastian
>
> Thanks!
> Owen
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
|
| Re: Separating JVM model and its implementation [message #1444520 is a reply to message #1444201] |
Tue, 14 October 2014 07:18 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Owen,
answers inline.
Am 13.10.14 21:48, schrieb Owen Arden:
> Hi Sebastian,
> Thanks for your reply. I did take the JvmModelInferrer approach
> initially, but got quite bogged down in linking and scope issues. I
> didn't mention before, but my language is an extension of Xtend. The
> necessary changes to the model inferrer ended up being difficult to
> integrate with the Xtend classes. Plus it began to seem like a lot of
> work for little payoff -- semantically, I *do* want to leave the Jvm
> model relatively unchanged. I just want to change the implementation of
> those semantics. The separation of the JvmModelInferrer from the
> JvmModelGenerator seems to give me this flexibility in the output
> direction (generating java source), but not the input direction (loading
> java classes).
I don't understand why you need to load stuff if basically the semantics
are the same. That sounds like a contradiction to me, but maybe I got
something wrong.
What you could always do is to put an XMI file next to the generated
*java files with a unambiguous naming convention. That could be
retrieved by your processing logic without further ado. But as I said,
maybe I'm off-track I did not fully understand the described scenario.
>
> An additional reason that the JvmModelInferrer is awkward for my needs
> is "erasable" typing information. I am extending the Xtend type system
> with types that represent security policies. These policies are mainly
> necessary at compile time. The only way I can see using the
> JvmModelInferrer to encode these types is to create a library of
> annotations that recapitulates the EMF model. This seems unnecessary
> given the availability of XMI serialization. Would you recommend this
> route even so?
No, not in any way would I recommend to extend Xtend. There is no API
policy for the Xtend implementation itself thus you can expect that each
new release or even each nightly build may break your implementation in
unexpected ways. You may want to chat with the maintainer of Jnario -
I'm sure he has some interesting insights on this.
Putting the necessary information into annotations appears to be a valid
approach in general. Depending on the retention policy, this would also
allow to read this stuff from produced class files - which is necessary
in multi-project setups. E.g. Xtend has some optimizations in that
regard: it does not necessarily read the referenced types from Xtend but
uses the produced Java files instead.
>
> I also looked into the Active annotation approach. Unfortunately,
> transformations like class --> interface do not seem to be supported.
> Am I wrong about that?
You can create a new interface and delete the class that was originally
derived. Changing the type of a concept from class -> interface or
annotation -> enum or in whatever direction is not possible since it
would be quite likely to produce an invalid JVM model from that.
Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
Powered by
FUDForum. Page generated in 0.04118 seconds
] 
Search
Help
Register
Login
Home
