User Tools

Site Tools


Dave Orme muses about agile and functional programming.

My current work emphasizes SOA applications using Scala, Kubernetes, and AWS with a React-based SPA front-end. I'm also interested in progressive web applications and developer tools.


Scala, Clojure, and FP


The Cloud

Data-First Development

Older work

Coconut Palm Software home

Donate Bitcoin:



Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL


Everything I say here is my own opinion and not necessarily that of my employer.


EMF as VEP's Model Description Language (2)

In a previous entry, I discussed some of the advantages and disadvantages of using EMF as the model-description language in VEP. Here we'll take a quick look at some of the implications of implementing the model this way.

The reason why EMF and VEP dovetail so nicely is that visual editors need to be able to describe and access meta-information about the user interface objects that they need to manipulate.

Java has two built-in ways to do that: java.beans.* and java.lang.reflect.*. But VEP needs to be language-neutral, so it can't use either of those two “standards” directly. It needs a language-neutral way to describe the same thing.

Enter EMF: EMF provides similar functionality to java.lang.reflect, but in a language-neutral format. It was designed for describing object models and manipulating them in a generic way using Java. But because EMF describes generic object models rather than Java object models, the object model that EMF describes could also be a C/C++ object model. Or a PHP object model. Or an XML document object model…

The result is that EMF as VEP-model-layer solves the language and architecture problem really neatly across several problem domains.


blog/emf_as_vep_s_model_description_language_2.txt · Last modified: 2014/10/17 22:08 (external edit)