Fwd: Need Design Help

[Mohan Embar]

Hi People,

This is a non-list-related question and I hesitated a
long time before posting it, but I value all of your
advice too much to deprive myself of it in this instance.
Stop reading now if you're not interested.

I promise to submit a patch or put out a new MinGW
build as compensation for everyone's wasted bandwidth.
This is a Win32-related issue, but you don't have
to understand Win32 (or C#)  to be able to answer it.

At my workplace, our general policy is Win32 C# Windows
Forms applications for GUI applications and Sun's Java on
the backend (standalone Java servers, servlets, etc.)
This stance is immutable, so questioning it is beyond our
scope. It is possible to call into a C DLL via C#, and
therefore, it is possible to embed a Java virtual machine
into a C# application via JNI. I've tested this out and
it works fine.

My idea was this: for small GUI applications which have
some business integration code which could potentially (but not
in the short-term) be promoted to a backend Java service,
wouldn't it be a good idea to code these classes up
in Java, call them in-process via JNI in the short term,
but leave the door open to reusing these on the back
end later on? This seems like a good idea to me, but some
people where I work are reacting like I've just landed from
Mars. If this is indeed a hare-brained idea for reasons
that I haven't considered yet, I'd appreciate it if you set me
straight.

Thanks again and sorry if I've wasted your time. I've attached
the original emails I sent on this subject.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

------- Start of forwarded message -------
From: Mohan Embar
Subject: Fwd: Need Design Help
Date: 7/13/2004 10:24:20 AM

Hi People,

I've proven the C# to Java calling approach
and it works fine. Here's a followup question.

I'm working on a C# Windows Forms project
which is multiuser. In the future, they may
have a need for a service which mediates and
manages the rich client requests. The service
could potentially open the application to
non-Windows clients. However, in the short term
they might be able to get by with a fat client
and no service. (This is subject to further analysis.)

My question is this: given that the C# to Java
stuff works, wouldn't it make sense to code the
[business integration layer], supporting classes and fat client
implementation in Java, call this in-process directly
from C#, but open the door to potentially migrating
most of this Java code to a service later on?
This approach makes a lot of sense to me, but people
have freaked out about my "unorthodox" solutions before,
so I wanted to get your reaction to this.

This morning, I checked how much memory my little
C# to Java stuff used and the application only
used about 14M. Of course, this is a toy application,
but I was surprised that the memory usage for a tiny
application with two virtual machines wasn't excessive
right off the bat.

Feedback?

-- Mohan

-------- End of forwarded message --------

------- Start of forwarded message -------
From: Mohan Embar
Subject: Fwd: C# to Java
Date: 7/8/2004 2:27:57 AM

Hi People,

Based on our discussion, I got a C# Windows Forms application to
make Java calls via P/Invoke to an umanaged C++ DLL which embeds
a JVM within the .NET process. After some hair-pulling to set things up, it works
beautifully.

Here are some screenshots, which also show Java exceptions being
displayed in the C# application.

[snip]

My approach is general-purpose and involves a generic string-in,
string-out interface. Solving this problem once should solve it
for all such uses, if we agree on the merits of this approach for
certain cases (reusing existing Java code directly from C# without fronting
it by a service).

-- Mohan

-------- End of forwarded message --------