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: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/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 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.