Ticket #4 (closed task: fixed)

Opened 13 years ago

Last modified 12 years ago

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) (diff)

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 13 years ago by curtis

  • Priority changed from major to critical

comment:2 Changed 13 years ago by curtis

  • Description modified (diff)

comment:3 follow-up: ↓ 4 Changed 13 years ago 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 13 years ago 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/ReflectedUniverse.java 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 12 years ago 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.

Note: See TracTickets for help on using tickets.