Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL to Java
OCL to Java [message #911247] Tue, 11 September 2012 04:30 Go to next message
ModelGeek Mising name is currently offline ModelGeek Mising name
Messages: 500
Registered: June 2011
Senior Member
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising name
Messages: 500
Registered: June 2011
Senior Member
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]

Report message to a moderator

Re: OCL to Java [message #911390 is a reply to message #911356] Tue, 11 September 2012 09:59 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising name
Messages: 500
Registered: June 2011
Senior Member
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising name
Messages: 500
Registered: June 2011
Senior Member
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising name
Messages: 500
Registered: June 2011
Senior Member
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising name
Messages: 500
Registered: June 2011
Senior Member
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4032
Registered: July 2009
Senior Member
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:
  


Current Time: Wed Aug 27 05:03:29 EDT 2014

Powered by FUDForum. Page generated in 0.02998 seconds