NOTICE! This is a static HTML version of a legacy LOCI Software ticket.

LOCI projects are now located on GitHub. The Bio-Formats project can be found here.

Ticket #4 (closed task: fixed)

Opened 2007-03-15T10:50:45-05:00

Last modified 2008-03-17T15:09:20-05:00

Bio-Formats native solution

Reported by: curtis Owned by: curtis
Priority: critical Milestone:
Component: bio-formats Severity: fatal
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by curtis)

Many developers, especially those working on applications for acquisition (e.g., Nico Stuurman and Nenad Amodaj), could benefit from an easy way to access Bio-Formats from native code. Since most of the I/O is done with our own classes (RandomAccessStream, RAFile, etc.) it should be fairly straightforward to port Bio-Formats to C++, though still a substantial amount of effort.

We would also need a native version of the OME-XML library (org.openmicroscopy.xml), but that port is largely a matter of replacing instances of Java DOM library usage with a C++ DOM library such as Microsoft's DOM implementation.

How to maintain two parallel implementations is another matter. SWIG is probably not the answer because it merely wraps C++ code with Java native bindings.

A possibility along different lines might be to point developers to something like  NewJ, a native Java implementation allowing easy porting of Java to C++, but unfortunately that solution is not free, and would restrict adoption. Or  GCJ might be useful, as it can  compile Java to native code, but my understanding is that such code is incompatible with Microsoft Visual C++.

Change History

comment:1 Changed 2007-03-20T14:21:04-05:00 by curtis

  • Priority changed from major to critical

comment:2 Changed 2007-03-22T14:16:10-05:00 by curtis

  • Description modified

comment:3 follow-up: ↓ 4 Changed 2007-03-29T16:51:54-05:00 by curtis

Chris Allan has pointed out  IKVM, which provides a .NET IL translator for Java bytecode. That is, you can convert JAR to DLL to provide a native library for your managed code.

comment:4 in reply to: ↑ 3 Changed 2007-11-30T13:25:38-06:00 by curtis

  • Severity set to fatal

Yang and Ansari have investigated IKVM.NET, and while it seems to work well in some ways, we are uncertain about performance. In addition, while Swing seemed to work, albeit with a high CPU usage, AWT and Swing are not officially supported (from the web site: "AWT and Swing are not presently functional. This is a low priority item for the project developers.").

As such, we are investigating an alternative solution wherein the native code can execute Java commands via a local loopback over a TCP/IP socket. This functionality is made much easier by the source:trunk/loci/formats/ code -- all that remains is to implement a simple network protocol for passing primitive objects, Strings and arrays back and forth, and we should have a powerful general-purpose system for native/Java interoperability.

comment:5 Changed 2008-03-17T15:09:20-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to fixed

Ansari and I have created a library called  JVMLink for communication between Java and non-Java code via sockets. Currently the library consists of a Java server in source:trunk/loci/jvmlink and a Microsoft Visual C++ client in source:trunk/loci/jvmlink/cpp. It should be very straightforward to implement the client side of the protocol in cross-platform C, Python or other language, and we plan to do so on an "as needed" basis.