Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370824

Summary:	[generator] Error caught while generating code model from an ecore with embedded OCL.
Product:	[Modeling] OCL	Reporter:	Adolfo Sanchez-Barbudo Herrera <adolfosbh>
Component:	Core	Assignee:	OCL Inbox <mdt-ocl-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	ed
Version:	unspecified
Target Milestone:	M6
Hardware:	PC
OS:	Windows 7
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=520440
Whiteboard:
Bug Depends on:	350891, 371394
Bug Blocks:

Description Adolfo Sanchez-Barbudo Herrera

2012-02-07 08:39:36 EST

Build id: 20120202-1513  (Juno M5)

Trying to do some generation of OclInEcore-edited .ecore.

Great !! the Tutorial.ecore code model generation doesn't fail anymore because of linkage errors.

However, the following simple file ends with a generator problem, which silently logs a NPE[1] in the error log:

package prueba : prueba = 'http://prueba'
{
	class Clase1
	{
		invariant : self.name.size() > 0;
		attribute name : String[?] { ordered };
	}
}

The problem is that not specifying a name for the invariant provokes no key creation for the annotation detail entry, and the OCLGenModelGeneratorAdapter assumes the key is present. 

I don't think EMF will deal with no keys in its detail map. Either you remove the optionality of the invariant name for oclinecore grammar, or you generate any random key for the entry, with any kind of pattern so it doesn't come up in the OclInEcore editor.

[1] 
java.lang.NullPointerException
	at org.eclipse.ocl.examples.codegen.ecore.OCLGenModelGeneratorAdapter.convertConstraintsToOperations(OCLGenModelGeneratorAdapter.java:140)
	at org.eclipse.ocl.examples.codegen.ecore.OCLGenModelGeneratorAdapter.doPreGenerate(OCLGenModelGeneratorAdapter.java:229)
	at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.preGenerate(AbstractGeneratorAdapter.java:250)
	at org.eclipse.emf.codegen.ecore.generator.Generator.generate(Generator.java:629)
	at org.eclipse.emf.codegen.ecore.genmodel.presentation.GeneratorUIUtil$GeneratorOperation.execute(GeneratorUIUtil.java:161)
	at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Comment 1 Ed Willink

2012-02-11 09:22:28 EST

NPE indeed caused by anaonymous invariant.

CD to Pivot can cope, but Pivot to Ecore can't becuase a null name is incompatible with the 'constraints' annotation summary. 

Changed to just ignore unnamed invariants. Bug 371171 raised to priovide a warning in the editor.

JUnit test added.

Pushed to master for M6.

Comment 2 Ed Willink

2012-02-29 16:52:23 EST

The plugin variant of this test fails on Hudson, so it has been disabled.

Re-instate once Acceleo moves to Guava.

Comment 3 Ed Willink

2012-05-03 01:48:27 EDT

(In reply to comment #2)
> Re-instate once Acceleo moves to Guava.

Re-instated, successful build on branch; pushed to master.

Comment 4 Ed Willink

2013-05-20 11:36:17 EDT

CLOSED after a year in the RESOLVED state.

Comment 5 Ed Willink

2021-04-18 04:09:37 EDT

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #0)
> package prueba : prueba = 'http://prueba'
> {
> 	class Clase1
> 	{
> 		invariant : self.name.size() > 0;
> 		attribute name : String[?] { ordered };
> 	}
> }

Once we add the SymbolicAnalysis, bug 520440, this fails with a mayBeInvalid on self.name.

Changing to 

 	attribute name : String[1] { ordered };

eliminates the hazard.

Comment 6 Ed Willink

2021-04-18 05:23:54 EDT

(In reply to Ed Willink from comment #5)
> Changing to 
> 
>  	attribute name : String[1] { ordered };
> 
> eliminates the hazard.

Yes, but that just makes the problem go away by requiring an EMF lower bound check.

Changing to 

	invariant : (self.name <> null) and (self.name.size() > 0);

should ensure that the lower bound is checked and guards the size comparison.

Just needs the self.name mayBeNull hypothesis for the size call to be detected as a contradiction. (The CG should factor out the CSE.)