[gme-users] Constructing a GME model using Java

Krishnakumar B kitty at dre.vanderbilt.edu
Thu Sep 7 02:28:38 CDT 2006


Hi Sandeep,

On Wed, 06 Sep 2006 03:30:58 PM -0500, Sandeep Neema wrote:
>> for an example.  You can also find usage of UDM's Java interface at:
>> 
>>
> https://svn.dre.vanderbilt.edu/viewvc/cosmic/trunk/CoSMIC/PIM/WSML/inter
> pr
>> eters/WSDLExporter/
>> 
>> Problem with UDM is that it is not integrated into GME, and hence
> requires
>> conversion of your GME model to UDM's XML model before you can use it
> with
>> Java UDM.
> [SN] 
> Kitty,
> You are perhaps referring to the metamodel and not the model. Yes, there
> are some disconnects in that you have to first convert your "GME
> metamodel" to a "UML metamodel".

Thanks for the clarification.  My explanation was a bit misleading.  The
disconnect at the metamodel level is less of an issue, since it's a one
time process.
 
> Subsequently, however, you can use the generated JAVA API to
> programmatically manipulate (construct) native GME models-

The problem with Java UDM is that unlike the C++ UDM, I cannot invoke the
interpreter from within GME.  This results in some usability issues with
it.  Another problem that I mentioned above is with debugging.  Since both
Java BON and Java UDM use JNI, it's impossible to step all the way into
functions.

I also tried to use C++/CLI, but I couldn't compile the generated UDM API
classes for PICML.  All of the generated classes were in a single file
PICML.{h,cpp} that was too huge, and I ran into internal compiler limits
when compiling in managed mode with VC7.1 (I didn't try with VC8).
Hopefully, the upcoming BONeXtender approach of generating a file per
element in the metamodel will also be adopted by C++ UDM (it already does
this for Java UDM) in the future.

That's why I mentioned C# since it is highly likely that it would be
possible to swich between native and managed run-times with the MSVC
debugger.  I might be wrong about that since I am definitely not an expert
in CLR.

IMHO, languages like C++ are going to fall out of favour because of the
lack of readily available libraries when compared to Java/C#/Python.
Especially for tasks like writing interpreters for design-time tools like
GME.  So it would be nice if GME provided a high-level supported API in one
of C# or Python (given the technical limitations with Java) in the future,
in addition to C++.  It would also eliminate the need for the C++ quiz held
to weed out students not proficient in C++ from the MIC course :-)

-kitty.

-- 
Krishnakumar B <kitty at dre dot vanderbilt dot edu>
Institute for Software Integrated Systems, Dept. of EECS, Vanderbilt University


More information about the gme-users mailing list