Eclipse Community Forums: OCL » Bug in generated code?

Home » Modeling » OCL » Bug in generated code?(Compiled OCL issue)

Bug in generated code? [message #1782367]

Thu, 22 February 2018 07:03

Eclipse User

Hello,

I'm trying to figure out yet another discrepancy between interpreted and compiled OCL. It seems that despite guarding for null in the invariant, the generated code accesses properties too eagerly resulting in NPE. In the attached example, the problem can be seen in org.eclipse.ocl.standalone.javaMM/javaMM.impl.MethodInvocationImpl.java#doesNotCallExit (line 431), where the "method" property is null. Both Complete OCL, interpreted OCLinEcore and EVL handle this as expected, so I can only presume it's a bug rather than semantic differences between OCLinEcore and Complete OCL.

Thanks,
Sina

Attachment: OCL_java_findbugs.zip
(Size: 1.25MB, Downloaded 222 times)

Re: Bug in generated code? [message #1782371 is a reply to message #1782367]

Thu, 22 February 2018 07:50

Eclipse User

Hi

The auto-generated Java code is more optimized; it exploits your declaration:

abstract class AbstractMethodInvocation extends ASTNode
{
property method#usages : AbstractMethodDeclaration[1];
property arguments : Expression[*|1] { ordered composes };
property typeArguments : TypeAccess[*|1] { ordered composes };
}

that promises that AbstractMethodInvocation::method cannot ever be null.
If you change the declaration to the more accurate:

property method#usages : AbstractMethodDeclaration[?];

the generated code has the now-required guard:

final /*@NonInvalid*/ AbstractMethodDeclaration method = this.getMethod();
final /*@NonInvalid*/ boolean ne = method != null;
/*@NonInvalid*/ Boolean result;
if (ne) {
/*@Caught*/ /*@Nullable*/ Object CAUGHT_and;
try {
/*@Caught*/ /*@NonNull*/ Object CAUGHT_eq;
try {
if (method == null) {
throw new InvalidValueException("Null source for \'\'http://www.eclipse.org/MoDisco/Java/0.2.incubation/java\'::NamedElement::name\'");
}
final /*@Thrown*/ String name = method.getName();

NB. It would be inefficient if OCL explicitly re-validated basic input model well-formedness that should have been checked by EMF's structural validator. An NPE is therefore an appropriate re-diagnostic.

-----

You appear to be using not-released Epsilon functionality so I cannot compile your BenchmarkUtils.java.

You appear not to be using the latest OCL/EMF functionality. It reports many violations in find_bugs.ecore, probably all directly/indirectly related to unsafe null navigation. Oops, EMF now refuses to generate until they are fixed (naively just change "." to "?."). https://bugs.eclipse.org/bugs/show_bug.cgi?id=531537 raised.

Description Resource Path Location Type
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'bd.modifier.inheritance' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 268 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'bd.modifier.static' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 267 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'bd.type.type' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 269 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 204 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 215 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 227 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 242 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 249 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.inheritance' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 696 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.inheritance' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 708 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.visibility' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 696 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.visibility' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model line: 708 /org.eclipse.ocl.standalone.javaMM/model/java_findbugs.ecore OCLinEcore Problem
The «body» 'javaMM::ClassDeclaration::hasCompareTo' is invalid: '"getMethods()->exists(method |
method.name = 'compareTo' and
method.parameters->size() = 1 and
method.parameters->first().type.type.name = 'Object' and
method.modifier <> null and
method.modifier.visibility = VisibilityKind::public and
method.thrownExceptions->isEmpty() and
method.returnType.type.oclIsTypeOf(PrimitiveTypeInt)
)"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «body» 'javaMM::ClassDeclaration::hasEquals' is invalid: '"getMethods()->exists(method |
method.name = 'equals' and
method.parameters->first().type.type.name = 'Object' and
method.parameters->size() = 1 and
method.thrownExceptions->isEmpty() and
method.modifier <> null and
method.modifier.visibility = VisibilityKind::public and
method.returnType.type.oclIsTypeOf(PrimitiveTypeBoolean)
)"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «body» 'javaMM::ClassDeclaration::hasHashcode' is invalid: '"getMethods()->exists(method |
method.name = 'hashCode' and
method.parameters->isEmpty() and
method.thrownExceptions->isEmpty() and
method.modifier <> null and
method.modifier.visibility = VisibilityKind::public and
method.returnType.type.oclIsTypeOf(PrimitiveTypeInt)
)"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «invariant» 'javaMM::ClassDeclaration' is invalid: '"
getMethods()->exists(method |
method.name = 'equals' and
method.modifier <> null and
method.modifier.visibility = VisibilityKind::public and
method.returnType.type.oclIsTypeOf(PrimitiveTypeBoolean)
) implies hasEquals()"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «invariant» 'javaMM::ClassDeclaration' is invalid: '"
getMethods()->exists(method |
method.name = 'compareTo' and
method.modifier <> null and
method.modifier.visibility = VisibilityKind::public and
method.returnType.type.oclIsTypeOf(PrimitiveTypeInt)
) implies hasCompareTo()"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'method.returnType.type'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «invariant» 'javaMM::ClassDeclaration' is invalid: '"
self.implements('Serializable') implies (
self.bodyDeclarations->selectByKind(FieldDeclaration) ->
exists(bd |
bd.name = 'serialVersionUID' and
bd.modifier._'static' and
bd.modifier.inheritance = InheritanceKind::final and
bd.type.type.oclIsTypeOf(PrimitiveTypeLong)
)
)"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'bd.modifier.static'
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'bd.modifier.inheritance'
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'bd.type.type'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «invariant» 'javaMM::VariableDeclarationExpression' is invalid: '"
self.modifier.visibility = VisibilityKind::public implies self.modifier.inheritance = InheritanceKind::final"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.visibility'
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.inheritance'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem
The «invariant» 'javaMM::VariableDeclarationStatement' is invalid: '"
self.modifier.visibility = VisibilityKind::public implies self.modifier.inheritance = InheritanceKind::final"
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.visibility'
The 'PropertyCallExp::UnsafeSourceCanNotBeNull' constraint is violated for 'self.modifier.inheritance'' java_findbugs.ecore /org.eclipse.ocl.standalone.javaMM/model Unknown EMF Problem

Regards

Ed Willink

Re: Bug in generated code? [message #1782375 is a reply to message #1782371]

Thu, 22 February 2018 08:03

Eclipse User

Hi Ed,

Thank you for the clarification. The metamodel was converted from an unconstrained Ecore metamodel, so I presume the issue is with the metamodel "allowing" null rather than a conversion issue from raw Ecore to OCLinEcore. In theory, those properties shouldn't ever be null anyway so that's probably a bug with the MoDisco Java Discovery feature.

Thanks,
Sina

Re: Bug in generated code? [message #1782379 is a reply to message #1782375]

Thu, 22 February 2018 08:21

Eclipse User

Hi

Traditionally the difference between [?] and [1] has not really mattered since during EMF construction/loading everything can be transiently null, but after using @NonNull in Java, a similar functionality seems obvious for OCL that can only be invoked for a non-transient model state..

I doubt that Modisco can often prove non-nullness so probably everything should be [?] for safety. Maybe you should raise a Modisco bug.

If you think this particular property cannot be null, then you need to investigate the 'bad' model that had a null, and the lack of an Ecore structural pre-validation.

Regards

Ed Willink

Re: Bug in generated code? [message #1782384 is a reply to message #1782379]

Thu, 22 February 2018 09:46

Eclipse User

Hi Ed,

Thanks again for your insight. In that regards, is there any downside to changing everything from [1] to [?] ? I presume [1] is more for readability and reducing redundant null checks but probably in my case it won't matter too much.

Re: Bug in generated code? [message #1782386 is a reply to message #1782384]

Thu, 22 February 2018 10:14

Eclipse User

Hi

If your import is from Modisco and the [1]'s are a fiction,. I would certainly recommend changing every non-Collection to [?].
Use of null values in Collections is rare, and arguably illegal in UML, so the default null-free Collections should probably be left as is.

As you write, a downside is that null checks cannot be bypassed during evaluation.

Another downside is that the OCL is fragile. Looking for examples in your code, it doesn't seem too bad since you get a lot of solid non-null values from collection iterators.

Once every non-collection can be null, many class-typed property accesses will be diagnosed (and the limited known-nullness checks will be stressed to correctly exploit e.g. "method.modifier <> null" guards). I steadily improve the depth of the null-safe analysis, but it's not perfect.

It really depends what sort of quality you are looking for. Given that your file name is java-findbugs, I presume you want rather good quality.

Regards

Ed Willink

Previous Topic:	EMF reflection in completeOCL (Pivot)
Next Topic:	def / derive in interactive OCL console

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Aug 30 04:50:27 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter