BT

InfoQ Article: In-Process JVM & CLR Interop

| by Floyd Marinescu Follow 38 Followers on Jan 29, 2007. Estimated reading time: 1 minute |
The two most popular managed environments (the JVM and the CLR) are in fact, nothing more than a set of shared libraries, each providing services to executing code such as memory management, thread management, code compilation (JIT), etc. Using both the JVM and the CLR inside the same operating system process is easy; in this new article, Ted Neward shows how and why.

Read In-process Interoperability

In the article Ted shows how to create a JVM inside a CLR process the old fashioned way and also how to use tools such as JACE, IKVM and JuggerNET to do two way interop more easily. Ted concludes explaining why this kind of interop may make sense:

 

Overall, it may seem less-than-obvious why in-proc interop is even on the table of possible approaches; aside from an obvious speed advantage (in that moving data around in a single process is far, far faster than moving data across a network, even a fast gigabit one), a number of other advantages include:

 

  • Centralization. In many cases, we want certain resources (database sequence identifiers generated within code, for example) to be inside of one-and-only-one process, to avoid complex synchronization code between processes.
  • Reliability. The fewer hardware tiers involved, the less vulnerable the entire system is to a single machine outage.
  • Architectural requirements. In certain scenarios, existing architectural requirements will mandate that all processing take place inside of a particular process; for example, the existing user interface for an application may already be coded in ASP.NET, and the interoperability part of the application is to drop a message into a JMS queue for an EJB message-driven bean to process. Sending the message out-of-proc to a Java service that simply drops the message into a JMS queue is a bit redundant and expensive, particularly given that JMS client code is typically straightforward. Putting the JMS client code inside the ASP.NET process (Codemesh offers a specialized version of JuggerNET proxies specifically for JMS client scenarios) offers the simplest way to keep with the "flow" of the existing architecture.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

cool! by anjan bacchu

Hi There,

I've been thinking about a GUI application(an HTTP filtering proxy) on windows -- the GUI portion using c# and the filtering proxy portion using java.

What other ideas have others have for an in-process interop program ?

BR,
~A

Re: cool! by Vitaly Shelest

Such code should be simple and without wrappers. See examples and API for .NET 1.1/2.0 (C#, J#, MCpp, VB) at

Object-Oriented JNI for .NET1.1 (low-level)
Object-Oriented JNI for .NET2.0 (low-level)

This API supports the same features as Regular JNI for C++.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT