3

I am making a proposal for a Python adapter to the Oracle NoSQL Database. The Oracle NoSQL Database runs as a stand alone java application, and at least in a Java program, you interface with it by telling your program the hostname and port to connect to, and some configuration settings. Then you make java calls off of the "kvstore" object that contains that configuration.

I'd like to make a Python library that essentially exposes Python versions of the java methods Oracle NoSQL has, and converts those to Java to speak with the running Oracle NoSQL application, but I'm not sure what technologies would be best to be able to do that.

Does anyone know what technology I would want to use? I'd rather not use Jython (so the application could run in a standard Python environment) or JNI (as it seems to have some nasty caveats.)

EDIT: The only potentially technology I've found so far is: Jpype Would it work for me?

Also, here are the ideal requirements the library would have. I would consider using Jython or JNI if one of them really did best match these requirements.

  1. Performance. The main benefits of Oracle NoSQL are performance and scalability, so that would be the most important component for the adapter.

  2. Easy to implement for the Python users. In order for the library to actually be used by Python programmers, it would have to relatively easy for them to use in a natural sort of way.

  3. Reliability. It would need to be possible for it to be trustworthy and bug free, while working on the platforms you naturally expect Python to work on. (This is what made me concerned about JNI. It sounds like it is platform dependent for its implementation, and can be error-prone.)

  4. Development speed. The last point of importance is that it be relatively fast to develop. The team of developers would enjoy learning Python or C, but we know Java better than any other programming langauge right now.

CorayThan
  • 17,174
  • 28
  • 113
  • 161
  • Reverse engineer the protocol and write a driver, perhaps? You've eliminated the pathways I would think of naturally. CPython + JNI, Jython, or posix sockets... – dwerner Feb 26 '13 at 22:26
  • 1
    It would help if you listed the criteria you are looking for. (It looks like you have one already "could run in a standard Python environment.) – Aaron Kurtzhals Feb 26 '13 at 22:26
  • @Dwerner I'd be happy to hear the benefits of those different options. I've listed the criteria now. I probably shouldn't have tried to outright nix Jython or JNI from the outset--it's more about how well it would meet the criteria. – CorayThan Feb 26 '13 at 22:37

1 Answers1

3

I've tried to answer each point in order, with it's own related notes.

  1. Performance: My opinion is that JNI would be the winner here, but I could be wrong, because Jython could be JITed as well.

  2. Easy to Implement: I am taking this as you mean easy to consume the library? That would depend entirely on how you build the API, 1 to 1 method calls, object handles, etc.

  3. Reliability: Jython is the clear winner here, because there is no room for error when you merely instantiate POJOs/ directly access the API right in the client code.

  4. Development Speed: JNI can be very tedious. You are essentially learning CPython modules, C, Python extensions, JNI and then referencing an existing API built in Java.

All in all, if you can make the jump, I think you'd get more benefit in the short term embedding Jython, mostly because there you can directly manipulate the API. I have personally embedded IronPython in a .NET codebase with good success. Yes you lose native speed, but the tradeoffs are hard to justify with the amount of C coding needed for a working JNI bridge. That said, you may well find projects like the one you listed (Jpype) that can do much of the legwork for you.

I would be asking what features of a native CPython runtime I need that you lose when going to Jython. Is your existing codebase in CPython heavily reliant on CPython native features?

Anyway, there's my attempt at an answer.

dwerner
  • 6,462
  • 4
  • 30
  • 44
  • With respect to 2, that is mostly what I mean. I'm also just not sure how big a difference it is for a Python developer to use Jython instead of CPython. Would it turn a lot of Python developers off of the idea of using the adapter because they didn't want to make the program only compatible with Jython, or would that not be a big deal? – CorayThan Feb 26 '13 at 22:57
  • Jython and IronPython are python in a syntactical sense, but they tend to differ a bit in real use from CPython because the API's leveraged in each environment are very different from CPython. That is if you lean on the Java class libs or .NET very much. You could make an API that would be easy to consume with JNI, but still it comes down to a taste/pragmatism balance. If you need to integrate with a significant codebase written in CPython, you may find it's worth it to expose the API there. If it's a new application, or just an extension to your existing one, I'd vote for the simpler solution – dwerner Feb 26 '13 at 23:02
  • Simpler solution == Jython, by far. – dwerner Feb 26 '13 at 23:02