I am working on some code using the EMF framework in Java, but it is really hard to use, e.g. I cannot implement OCL-like query API on top of EMF which would be type-safe.
One of the reasons is that
eGet() for a
EStructuralFeature returns just an
EObject. So anything I would write must use much of null checking, type checking and type casting which is unsafe, not performant and cannot be generalized in a reusable way.
Why doesn't EMF generate dummy implementations with
EObject wrappers for arbitrary
EObject and hence the
EClass interfaces even with simple throw
UnsupportedOperationException is really a pain (the APIs are too big). The same holds for the
eContainer() method which makes navigating the model upwards painful.
The same method is used for accessing simple attribute values (which can be of any Java type) and traverse relationships to other modeled objects, and those can be single or multivalued.
EMF provides generic mechanisms for checking whether an object is an instance of an EClass, or if an EClass is assignable to another, so I don't really see the problem with that.
The eGet() method is part of the EMF reflective API. As EMF can wrap any serializable object you cannot restrict the returned object of such a reflective API.
Why do you need to use this reflective API instead of the generated Java implementation of your ecore model? This way you will have all the direct well typed API to manipulate your domain objects.