Eclipse Community Forums: OCL

Home » Modeling » OCL » OCL to Java

Tue, 11 September 2012 04:30

Eclipse User

Hi,

I am working to create ecore models programmatically and creating multiple different xmi (Ecore's instantiation) programatically and using setting delegates to fetch the derived values in java. This process is quite time taking as delegates are not thread safe.

In JUNO, are delegates thread safe?

Is there any functionality available to prgramtically generate java compiled version of Ecore model and then instantiate java compiled version to fetch the derived values?

Regards,

Re: OCL to Java [message #911326 is a reply to message #911247]

Tue, 11 September 2012 07:38

Eclipse User

Hi

On 11/09/2012 09:30, ModelGeek Mising name wrote:
> In JUNO, are delegates thread safe?
No. If you warm everything up on a single thread, it might then work on
multiple threads, but you need to keep your fingers crossed.
>
> Is there any functionality available to prgramtically generate java
> compiled version of Ecore model and then instantiate java compiled
> version to fetch the derived values?
Yes. Juno provides an experimental code generator; see the Code
Generation Tutorial in the OCL documentation.

The code generator gives a modest speed improvement at present (3 times)
in addition to migrating parsing overheads to compile-time.

I am currently making significant improvements, keeping thread safety in
mind, and expect to get at least a factor of ten and perhaps much more
improvement for Kepler or perhaps even an early intermediate release.

Regards

Ed Willink

Re: OCL to Java [message #911356 is a reply to message #911326]

Tue, 11 September 2012 08:45

Eclipse User

Great!

Kepler:

Will kepler be the new version for Eclipse(Next version to JUNO)?
When is the expected launching date?

JUNO:

Can i generate java code and run ANT task to compile that and then dynamically instatantiate compiled java classes to represent specific XMI snenario?
Can you please give me hint regarding this process?

Regards,

[Updated on: Tue, 11 September 2012 08:45] by Moderator

Re: OCL to Java [message #911390 is a reply to message #911356]

Tue, 11 September 2012 09:59

Eclipse User

Hi

Yes Kepler is Juno + 1; released June 26th 2013.

The current generator is integrates into genmodel, so there is nothing
to do.

The underlying technology is Acceleo and it is intended to be extensible
for QVT, and Acceleo itself but that is distinctly future. The only hint
I can give you is to look at the org.eclipse.ocl.examples.codegen plugin.

Dynamic generation of Java is on my todo list once I find out how to do
it. And realistically I have to do it so that I can rerun all the
existing JUnit tests without significant change.

Regards

Ed Willink

On 11/09/2012 13:45, ModelGeek Mising name wrote:
> Greate!
>
> Kepler:
>
> Will kepler be the new version for Eclipse(Next version to JUNO)?
> When is the expected launching date?
>
> JUNO:
>
> Can i generate java code and run ANT task to compile that and then
> dynamically instatantiate compiled java classes to represent specific
> XMI snenario?
> Can you please give me hint regarding this process?
>
> Regards,
>
>
>

Re: OCL to Java [message #911868 is a reply to message #911390]

Wed, 12 September 2012 09:33

Eclipse User

thanks for information!

One more question. In kepler, delegates will be completely thread safe? and what is the possibility for early intermediate release?

Actually i am using delegates and it is important for me know so i can plan.

thanks!

Regards,

Re: OCL to Java [message #911971 is a reply to message #911868]

Wed, 12 September 2012 13:18

Eclipse User

Hi

On 12/09/2012 14:33, ModelGeek Mising name wrote:
> One more question. In kepler, delegates will be completely thread safe?
Never say 'completely'... it's untestable; however the intent will be to
be thread safe if you generate Java code, which means you aren't using
delegates at run-time.

> and what is the possibility for early intermediate release?
Quite good. The new evaluation is much better, and uses no Kepler-only
technology. I'll aim at getting it out for EclipseCon Europe. (late
October).

Regards

Ed

Re: OCL to Java [message #912252 is a reply to message #911971]

Thu, 13 September 2012 03:48

Eclipse User

Thanks for information.

Is there any plan to make delegates thread safe when used at run time?

Actually i am creating ecore at rum time and then i need to make thousands of xmi's at run time and i use delegates at run time so it is really my area of concern.

Currently, delegates are not thread safe so i can not have parallel execution for delegates so it is really slow process and i want to increase performance.

In future, if delegates will be thread safe then it will be extremley helpful to increase performance. If not then i need to look for other solution like translating whole ecore into java compiled version at runtime and use complied java code to create N number of xmi.

Currently, i have checked that JUNO does offer OCL to java conversion without using delegates that is nice. Now my problem is to generate that code at run time, compile it and use that to create N numbers of xmi. Is there any tutorial/help available addressing specific area?

Regards,

Re: OCL to Java [message #912433 is a reply to message #912252]

Thu, 13 September 2012 11:18

Eclipse User

Hi

I'm not clear why you want delegates at run-time; there is significant
overhead and no thread-safety. Since direct Java avoids these problems
making delegates thread safety is very low priority.

I look forward to you contributing a run-time activation of the OCL to
Java conversion so that others may use it too. My recollection is that
Java 6 introduces a Java compiler API which may be helpful.

Regards

Ed Willink

On 13/09/2012 08:48, ModelGeek Mising name wrote:
> Thanks for information.
>
> Is there any plan to make delegates thread safe when used at run time?
>
> Actually i am creating ecore at rum time and then i need to make
> thousands of xmi's at run time and i use delegates at run time so it
> is really my area of concern.
>
> Currently, delegates are not thread safe so i can not have parallel
> execution for delegates so it is really slow process and i want to
> increase performance.
>
> In future, if delegates will be thread safe then it will be extremley
> helpful to increase performance. If not then i need to look for other
> solution like translating whole ecore into java compiled version at
> runtime and use complied java code to create N number of xmi.
>
> Currently, i have checked that JUNO does offer OCL to java conversion
> without using delegates that is nice. Now my problem is to generate
> that code at run time, compile it and use that to create N numbers of
> xmi. Is there any tutorial/help available addressing specific area?
>
> Regards,

Re: OCL to Java [message #912563 is a reply to message #912433]

Thu, 13 September 2012 15:19

Eclipse User

Thanks for explanation.

I would really like to contribute in this regard.

To make sure that i understood completely. I would reiterate the solution.

Kepler(or earlier release) will provide facility to generate Java code from Ecore which will be direct conversion from OCL to Java(avoiding delegates) and this generated code will be thread safe.

Now to avoid delegates at run time. We need to generate java code from Ecore at run time and utilize Java Compiler API to compile generated code and use this compiled java code to instantiate N numbers of Xmi?

thanks for assistance!

Re: OCL to Java [message #912572 is a reply to message #912563]

Thu, 13 September 2012 15:38

Eclipse User

Hi

Yes, but...

I've no idea what "N numbers of Xmi" means.

I'm not clear why you can't use genmodel to generate Java at
compile-time. Why is your Ecore dynamic?

Regards

Ed Willink

On 13/09/2012 20:19, ModelGeek Mising name wrote:
> Thanks for explanation.
>
> I would really like to contribute in this regard.
>
> To make sure that i understood completely. I would reiterate the
> solution.
>
> Kepler(or earlier release) will provide facility to generate Java code
> from Ecore which will be direct conversion from OCL to Java(avoiding
> delegates) and this generated code will be thread safe.
>
> Now to avoid delegates at run time. We need to generate java code from
> Ecore at run time and utilize Java Compiler API to compile generated
> code and use this compiled java code to instantiate N numbers of Xmi?
>
> thanks for assistance!
>

Re: OCL to Java [message #912782 is a reply to message #912572]

Fri, 14 September 2012 03:22

Eclipse User

Actually the nature of application i am working with requires to have dynamic Ecore becuase user can change ecore at run time and then can have N number of instantiations. To be precise, in my application Ecore is never(almost never) complete or final. User keep on changing it and instantiating it.

With N number of Xmi means N number of instantiation for Ecore where N represents a integer varies between 10000 to 10000000. And all this has to be done at run time.

Thanks alot!

Re: OCL to Java [message #912830 is a reply to message #912782]

Fri, 14 September 2012 05:03

Eclipse User

Hi

Ok. You definitely need run-time OCL to Java to byte code.

My improvements to the OCL code generation affect the templates, but the
basic problem of activating the OCL to Java transformation so that the
result is placed on a classpath location that a Java to byte code
compilation can exploit remains.

If I rummage around, I can probably find my experimental run-time
activation; it was the classpath that was holding me up. Let me know if
you want to tackle this.

Regards

Ed Willink

On 14/09/2012 08:22, ModelGeek Mising name wrote:
> Actually the nature of application i am working with requires to have
> dynamic Ecore becuase user can change ecore at run time and then can
> have N number of instantiations. To be precise, in my application
> Ecore is never(almost never) complete or final. User keep on changing
> it and instantiating it.
>
> With N number of Xmi means N number of instantiation for Ecore where N
> represents a integer varies between 10000 to 10000000. And all this
> has to be done at run time.
>
> Thanks alot!
>
>
>

Re: OCL to Java [message #941450 is a reply to message #911971]

Fri, 12 October 2012 10:25

Eclipse User

Hi

I've just pushed an updated code generator tom GIT master that is
between 3 and 30 times faster than the Ecore-based or Pivot-based
interpreters.

The code generated approach is nominally thread-safe; ant suggestions on
tools that might improve on 'reasonable endeavours'?

Testing of the code generator is currently limited to about 30
constraints used during editor validation and four speed benchmarks, so
it's not yet ready for a formal release.

Expect further non-trivial speed-ups once the current direct OCL to
Java with Acceleo is prefaced by some QVTo strategic analyses to resolve
Common SubExpressions, Potential Types and Null/Invalid handling.

An N-build should be available at
http://www.eclipse.org/modeling/mdt/downloads/?project=ocl soon
(tomorrow); it's available now at
https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-tools-kepler-master/lastSuccessfulBuild/artifact/.

Come to the Fast, Faster and Super-Fast queries talk at EclipseCon
Europe to hear more.

Regards

Ed Willink

On 12/09/2012 18:18, Ed Willink wrote:
>> and what is the possibility for early intermediate release?
> Quite good. The new evaluation is much better, and uses no Kepler-only
> technology. I'll aim at getting it out for EclipseCon Europe. (late
> October).

Previous Topic:	Read OCL from text file
Next Topic:	Reverse sort for sortedBy()

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:13:33 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter