Eclipse Community Forums: EMF » [SOLVED] Hello, I have hit the "...exceeding the 65535 bytes limit". Any help?

Help

Home

Home » Modeling » EMF » [SOLVED] Hello, I have hit the "...exceeding the 65535 bytes limit". Any help?

Show: Today's Messages :: Show Polls :: Message Navigator

[SOLVED] Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1792658]

Fri, 20 July 2018 14:55

Pratiksha Dalal

Messages: 31
Registered: May 2018

Member

Hello,
I posted this originally in Sirius forum only to realize that this is actually EMF problem.
My project requires hundreds of variables and when I defined them in the ecore and generated the edit/editor codes, I am getting the error "The code of method <my package>.. is exceeding the 65535 bytes limit" error.
Has anybody come across this? Any possible solutions?
I tried splitting my ecore in to multiple, but looks too complex to define them in one genmodel (base classes in one ecore while derived classes in another etc).

The problem is that the genmodel tries to initialize all the variables defined in main package and sub-package in the same method and that's creating problems. In my opinion, the genmodel should have created separate methods to initialize variables in subpackages.

Pointers to any solution or section of any tutorial that touches these aspects, would greatly appreciated!
-Pratiksha

[Updated on: Mon, 23 July 2018 09:51]

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1792663 is a reply to message #1792658]

Fri, 20 July 2018 15:54

Christian Damus

Messages: 1270
Registered: July 2009
Location: Canada

Senior Member

You need to use the genmodel option to "Initialize by loading" (in the Model category of the properties IIRC).

See the org.eclipse.uml2.uml plug-in for an example.

HTH,
Christian

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1792665 is a reply to message #1792658]

Fri, 20 July 2018 15:58

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

A couple of options may help.

Set Model->Literals Interface to false.
Set Model->Initialize by Loading to true.

Regards

Ed Willink

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1792714 is a reply to message #1792663]

Mon, 23 July 2018 06:49

Pratiksha Dalal

Messages: 31
Registered: May 2018

Member

Thanks for ur reply will try and let you know
Pratiksha

[Updated on: Mon, 23 July 2018 06:55]

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1792730 is a reply to message #1792663]

Mon, 23 July 2018 09:52

Pratiksha Dalal

Messages: 31
Registered: May 2018

Member

Thanks Christian and Ed! It solved the issue. Whew!

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1833971 is a reply to message #1792730]

Thu, 29 October 2020 09:29

Dimitar Peikov

Messages: 1
Registered: July 2009
Location: Sofia, Bulgaria

Junior Member

I've experienced same issue inside doSwitch(int classifierID, EObject theEObject) - due to long model (Autosar0048.ecore @ Rhapsody).
What if this switch case generates something like:
case Autosar00048Package.AUTOSAR: return case_AUTOSAR(theEObject);
With this approach I was able to solve my problem, however still looks to shift the problem away.
Can the switch/case be transformed into array functional redirection and use classifierID as index? Which shall be the most effective approach there?

Or the problem of such complex and heavy models needs logical decomposition in sub-packages and compositional merge at runtime?

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1833990 is a reply to message #1833971]

Thu, 29 October 2020 14:28

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

I suppose the body of each case block could be factored out to a separate method to reduce the byte code size of the doSwitch method.

But it's doubtful that anyone would fund the development of such a new feature.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Hello, I have hit the "...exceeding the 65535 bytes limit". Any help? [message #1833991 is a reply to message #1833990]

Thu, 29 October 2020 14:47

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Refactoring could be tedious manually and not obviously easy to automate, but there is another solution which is actually rather faster since it tends to dispatch directly rather than search the hierarchy. (If the Switch is not feasible you can provide an empty @generated not to keep it small.)

Eclipse OCL provides an extensible Visitor framework generator.

You can see some auto-generated visitors and support in: https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/plugins/org.eclipse.ocl.pivot/emf-gen/org/eclipse/ocl/pivot/util/

You can see the auto-generator invocation in: https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/examples/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GenerateCGModels.mwe2

You can see a (manually coded) visitor in: https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/examples/org.eclipse.ocl.examples.codegen/src/org/eclipse/ocl/examples/codegen/analyzer/CG2StringVisitor.java

The auto-generator injects e.g.

/**
	 * {@inheritDoc}
	 * @generated
	 */
	@Override
	public <R> R accept(@NonNull CGModelVisitor<R> visitor) {
		return visitor.visitCGCollectionExp(this);
	}

into your Impl classes, which must have a common root from which accept is overridden.

Regards

Ed Willink

Report message to a moderator

Previous Topic:	Source not found Edit Source Lookup Path
Next Topic:	[CD0] Read lock owners not being cleared after closing view

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 15:16:08 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter