Eclipse Community Forums: OCL » Calling out from OCL to Java

Home » Modeling » OCL » Calling out from OCL to Java(OCL to Java calls)

Calling out from OCL to Java [message #1860289]

Wed, 26 July 2023 18:48

Eclipse User

I see from https://www.eclipse.org/forums/index.php/m/1860264/#msg_1860264 that the ability to call from OCL to Java functions is 'in the works'. As far as I can tell it isn't actually in a release yet. The above bug report indicates it was targeted for the 2022-06 release. Did that happen?

If so, is there any documentation? or tests/examples? The tests in https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196729/1/tests/org.eclipse.ocl.examples.xtext.tests/src/org/eclipse/ocl/examples/pivot/tests/EvaluateStringOperationsTest4.java#341 are all I've found so far - but they aren't part of the main branch yet AFAIK

Re: Calling out from OCL to Java [message #1860292 is a reply to message #1860289]

Thu, 27 July 2023 02:40

Eclipse User

Hi Steve

Partial 'documentation' can be found in https://eclipse.dev/ocl/docs/publications/OCL2022Library/OCLLibrarySupport.pdf and some insights in https://eclipse.dev/ocl/docs/publications/OCL2022CG/OCLCodeGeneration.pdf

The obvious support for Java calls was quite simple and is 'done'. But since many useful Java functions may be static and may need calling from OCL2Java generated code, the support rippled to pick up a number of outstanding related deficiencies; full support for static operations (and properties) and to the CG idioms for them. This in turn rippled to pick up the missing support for OCL2Java of Complete OCL-defined additional operations and properties. The number of extra CG idioms motivated a refactoring of some over-large CG switch-trees to polymorphise the CG idioms. In principle this is all done and tested, or rather reasonably well exercised. I was however disconcerted by the number of CG bugs that I discovered while testing and so lacked confidence that users wouldn't find a few more howlers.

A further problem arises with Eclipse and API policies. Released code should not break in a subsequent release without a major version change. I endeavour to respect this discipline for the primarey ocl.pivot but not secondary ocl.xtext plugins. The refactoring for statics makes API changes for which I have not yet tried to retrofit compatibility signatures. (If you study the code you will already find too many @deprecated compatibility methods that have aspirational rather than tested compatibility.)

https://www.researchgate.net/publication/346268547_Reflections_on_OCL_2 provides important OMG OCL background. The original/classical Eclipse OCL was developed by IBM and made a reasonable stab at doing what the specification neglected to specify. However API compatibility made it impractical to resolve poor Eclipse OCL design decisions or to move forward to resolve OMG OCL issues. I therefore initiated the unified/pivot OCL to prototype solutions to many of the OMG OCL problems. Sadly it has taken me far too long to realize how deep seated some of the OMG OCL problems are. It is necessary to implement just the spirit rather and ignore some of the letter of the specification and so release the Pivot OCL from its own poor design decisions driven by too close adherence to the specification. https://bugs.eclipse.org/bugs/show_bug.cgi?id=509309 is the planning bug that roots a tree of changes that can only happen once the Pivot OCL goes through a major version change.

The static/Java call support ripples to require a major version change and there is a huge backlog of simplifications that such a change unlocks and am keen to do since development progress is depressingly slow without some of the changes. I am currently working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=581543 and related simplification of the Pivot metamodel impl,ementation.

Probably the easiest solution to help you is to make a 'next-version' available as an N-build so that you can download/install it from e.g. https://ci.eclipse.org/ocl/job/ocl-/353/artifact/releng/org.eclipse.ocl.releng.build-site/target/org.eclipse.ocl-6.19.0.N20230319-1135.zip
If you can live with an 'official' bootleg, I'll try to set that up.

Regards

Ed Willink

Re: Calling out from OCL to Java [message #1860387 is a reply to message #1860292]

Wed, 02 August 2023 12:24

Eclipse User

I can live with that - I'm using this as part of a startup (if you're curious, see https://github.com/Epistimis - the repos aren't public but the overview is there), so I'm in experimentation phase anyway. And I'm pretty good at breaking things so I'll likely find bugs if they are there. And I'm happy to help - I've gotten a lot out of OSS in the past - it would be good to give back.

[Updated on: Thu, 03 August 2023 12:48] by Moderator

Re: Calling out from OCL to Java [message #1860435 is a reply to message #1860387]

Fri, 04 August 2023 13:24

Eclipse User

I'm assuming the supplied link in your comment is just an example - because I get a 404 when I follow it.

Re: Calling out from OCL to Java [message #1860449 is a reply to message #1860435]

Sun, 06 August 2023 13:16

Eclipse User

All the link look good to me except the e.g. link that indicates what could be available.

Re: Calling out from OCL to Java [message #1860461 is a reply to message #1860449]

Mon, 07 August 2023 15:57

Eclipse User