[FoRK] Top general purpose languages: Practical choices for app logic / presentation & web / server apps

Stephen Williams sdw at lig.net
Tue Jan 18 15:24:35 PST 2011

On 1/18/11 3:09 PM, Ken Meltsner wrote:
> If you're looking at Java and .Net compatibility, check out IKVM.net (
> http://www.ikvm.net/):
> IKVM.NET is an implementation of Java for Mono<http://www.go-mono.org/>  and
> the Microsoft .NET Framework<http://msdn.microsoft.com/netframework/>. It
> includes the following components:
>     - A Java Virtual Machine implemented in .NET
>     - A .NET implementation of the Java class libraries
>     - Tools that enable Java and .NET interoperability

I believe I have an old bookmark for this somewhere from a while ago, but had forgotten about it.  Thanks!  Glad they have been 
improving it.  If it works very well, seems like a great way to make .NET more usable by supporting use of key Java libraries.

> Admittedly, this is code-level (source or byte-code) compatibility, not
> seamless Oracle JVM connectivity, but it might be sufficient.  Or you can
> look at some sort of SOAP, COM, etc. bridge between the two environments.
> The latter is ugly, but at least you don't have to deal with geometric
> unreliability if the two environments are relatively independent (e.g.
> P(total)= P(java) * P(.Net) vs. limited functionality with the same
> reliability as the .Net environment).

In past projects I've often built a TCP connection between components, Java/.Net implementing XML RPC over BEEP for instance.
Lately, I've been working out details to create a more or less standard method for shared memory "command line" / streaming 
between applications.  This is doable on Android in a nice way with a new semi-standard IO-like shared memory setup API.  I also 
need it for desktop use.  I've found a reference where it was used to resolve licensing issues: using a GPL app as a subsystem 
in a proprietary app without linking and in a way that the app remains independent and replaceable.  I may use it for that same 
reason, however it is also a great way to use a lot of tools efficiently.

My plan is to create a standard command line argument that indicates: "don't use stdin/stdout, switch to shared memory app mode 
X with identifier Y".  Much like a fastCGI interface, this should allow the app to "invoke" the tool with new "command lines", 
feed it input, and retrieve output, all with shared memory.  It should support full buffering or short buffers with chunking.  
The app can be one shot or reusable, with either side allowed to indicate a restart need.

I may fold into this some ideas about structured input/output in XML, JSON, Google Buffers, and/or other graph languages.  This 
should be everywhere anyway: /proc in Linux, ls, etc.  We've talked about this before.

> Ken Meltsner


More information about the FoRK mailing list