Sunday, February 01, 2009

Looking for an open source ERP that doesn't suck? Well there is at least one: OpenERP. Like it or not it's Python based. For most of the things this is a perfect fit, but let's face it, Python has less enterprise acceptance and the lower layers of that ERP could also have been powered by a powerfull virtual machine. And since building a new ERP can't really take less than 3 years, the situation will hardly evolve any time soon, so we better deal with it: I bet my money OpenERP will now take the market by storm, I don't see anything stopping it to take the lead, at least for the next 5 years.

So I wanted to show the world that it was possible to back OpenERP by the Java platform, much like it's now being admitted that Java is the best bed for Ruby on Rails applications thanks to JRuby. I built a proof of concept. Now I hope some get the message and join efforts to make it happen. I'll hardly finish that journey in my spare time, but hopefully, some people start to release how important this is and how close we are and help covering the extra miles to get it in production running on Java. Of course, OpenERP doesn't need to run Java to be the best ERP already, it is just that it could be even better. And if you want to help out, I'll be there too.

what about the claimed Java based ERP's?

I've been myself a Java programmer since around 2003, even created my first open source project on Sourceforge back in 2004 (EmSim http://sourceforge.net/projects/emsim/), later on I used those skills in a variety of advanced projects when working at Amadeus and Smile.fr. But, like it or not, after deep investigation, my conclusion is that the best open source ERP was coded in Python. I've looked deep inside Java based or claimed ERP's such as Ofbiz, Neogia, JFire, Compiere, Openbravo, Adempiere but those were too limited in my opinion. Basically, the trouble is that those 'Java' based ERP don't rely on true object oriented modeling since the ground up, some of them being even more SQL based then really Java based. I could explain in deep details why, but this is beyond the scope of this post.

So my conclusion was that even if I needed to learn Python, I would get the work done faster with OpenERP than with any of those existing Java based ERP's. My experiments proved me that I was right. With OpenERP, extending the relational model, the forms and making it fit to my needs was faster than with any of the other tried ERP's, even while being a Python noob. One year later, with a few successful implementations behind me, I'm only recommending it more than ever.

But wouldn't it be great to port OpenERP on the Java platform?

The benefits of porting OpenERP on Java are beyond the scope of this post. Still, here is a short list:

Noticeable speed up. Even if the Python layer peaks up at 40% of the CPU load under high concurrent loads, getting twice as fast would be noticeable. If Jython get as optimized as JRuby which is 2 to 5 times faster than C Ruby, we will go there.

Real multithreading and less memory use under huge loads (CPython scales using process and sharing nothing accross runtimes because it has a Giant Lock in its interpreter, much like PHP or Ruby). The expected benefit there is much like what benchmarks prove for heavily loaded JRuby on Rails applications.

One click installation on lots of hardwares (imagine how easy it will be to sale to large companies when you will say it's only a .war you pu on your Tomcat server).

Penetration in large companies where Java tends to rule more than Python

Easier and solid cross database support thanks to the unified JDBC API.

Larger community for OpenERP. OpenERP is certainly the open source ERP with the largest active open source community. But just imagine how large it could get when you managed to connect with the Java community, telling them: hey, we are somewhat Java based too. If you know Java you'll be able to leverage those skills to get the job done in OpenERP. Again, JRuby proved here that connecting communities was possible.

Possibly larger fundings and exposure for OpenERP. Openbravo certainly had the large fundings it had by playing on its Java image which as a broad acceptance in the enterprise world.

And the best of all: cross language implementation: by leveraging Jython, you would be able to call the best existing Java lib (there are some good ones like JDBC, JCR, JMX, JMS, ESB's, SOAP...), but also externalize some code pieces where speed is critical to Java, meaning an easier way to reach C speed (a warmed up Java6 runs at C speed and sometimes faster) than writing C bindings.

Jython will probably ends up implementing the MOP (Meto Object Protocol) that makes it possible to share OBJECTS between JVM based languages such as JRuby, Javascript, Scala, Clojures, Groovy... Meaning that more people could adapt OpenERP to meet their needs using the language they already master. That means you could code OpenERP modules in Ruby for instance and that's not a small thing, while preserving backward compatibility. Of course, published modules would have to keep beeing closely controlled, but at least one shot veticalization modules could offer more options.

Because it's fun and we can do it.

What does it take?Well, Jython is really alive again. Notice that Microsoft hired the orginial Jython creator to create Iron Python on the .Net platform. Next, by 2008, Sun Microsystem hired the two Jython leads, Ted Leung and Frank Wierzbicki to make it Python a first class citizen on the Java platform again. Espcially, JRuby recently proved that the JVM was able to run dynamic languages faster than their native C interpreter that don't come up with such a sophisticated virtual machine. So in theory the future is bright. A 2.5 Python compliant Jython is expected by February and the current trunk largely reflecting it already.

Still, the trouble, comes with native libraries. Since Python tends to be somewhat slow, Pythonistas tend to back lot's of Python libraries by C extensions to provide extra speed. The trouble is that the Jython interpreter, sandboxed in its virtual machine environment can't invoke the same C extension, mostly because it doesn't work the same at the lowest levels.

In some places, OpenERP uses such libraries. Some of them are psycopg2, mx.DateTime, libxml2, libxslt. Overall there aren't too many fortunately so that's why this shouldn't be too hard to have a full blown OpenERP running on the JVM. The common strategy here is to set up a wrapper over existing Java libraries in place of those C extensions. Also notice that in the near future, Jython might also support CTypes, a standard way of building C extensions for Python. This is largely because Jython is benefiting here from the fantastic JRuby work of Wayne Meissner around JFFI (Java Foreign Fuction Interface). Other synergies exist, like the Da Vinci Machine, or Invoke Dynamic bytecode instruction that would help the JVM speeding up dynamic languages while optimizing memory usage.

Current status:After some two days of heavy hacking, I'm getting:

OpenERP server starting powered by the last Jython Java based interpreter, backed by the regular JDBC Postgres driver over a standard Java JNDI database connection pooling, instead of Pyscopg2.

It answers most of the webservices calls, be it from the clients or from the webservice API. The largest thing that isn't working here is datetime operation that are using the mx.DataTime library that isn't yet fully supported.

Also, views don't work yet (the fields_view_get method). This is due the current XML and XPath limited support. Everything need is available on the Java plateform, but it should be wrapped properly to fake the Python API OpenERP is expecting there.

Next stages:

I guess that faking the required xpath and xml API would be great. That shouldn't be that hard given that OpenERP only use a few things in those API. We should only wrapp them over Java libraries such as Xalan.

As for the mx.DateTime trouble, the OpenERP team said they are ready to move away from it. Indeed mx.DateTime has a bug with dates before 1970. That's why the Tryton fork moved away form it, proving the thing is possible (they only use it marginaly for parsing, but alternative can be found). Advised by Jim Baker from Jython, it appears that the standard python datetime, datetime.timedelta and the http://labix.org/python-dateutil library might be used instead. So aside from helping getting rid of mx.DateTime, we probably won't have much work here.

Once all that is working, the Java based OpenERP server will already be in pretty good shape to be used in production.

Of course, ideally we would package the whole thing within a standard J2EE war package and serve it with a standard servlet container such as Tomcat or Glassfish. The idea there is to write a servlet connector that will use standard Java servlet instead of the python SimpleXMLRPCServer. Then we would route HTTP request to a pool of Jython runtimes and the appropriate OpenERP server layers, much like others do with Django on Jython or the Glassfish JRuby on Rails gem supported by Sun Microsystem.

Once performance starts to proves better than CPython (Jython and JRuby guys are expecting this to happen by 2009 already) and once large companies show interrest in deploying OpenERP over their existing Java stack, may be the OpenERP team starts to support it officially and provide alternative Java based layers to increase performance even more or provide extra features (like SOAP, JMS async messaging, ESB like Mule or ServiceMix, a REST layer, JMX remote monitoring, OpenTerracotta clustering...)

Steps to follow to test the current Jython powered version:

Requirements:

you should know how to start a regular OpenERP v5 server

you should have an existing OpenERP v5 database to test again

you should have Java installed (1.6 advised)

First you have to grab a recent Jython interpreter. Make sure you have a recent version of Java installed (1.6 advised) and then grab Jython:get a fresh version of Jython, and build it:

now, put the jython-dev/dist/bin/jython command in your path.now if you type$ jython

that should bring you a Python 2.5, java based commande line interpreter.

Now grab my public branch of the OpenERP server:$ bzr branch lp:~rvalyi/openobject-server/trunk-java-jython

As for the addons, you can use your regular OpenERP v5 addons, or grab them from here:$ bzr branch lp:openobject-addons

Now open the trunk-java-jython/bin/tools/config.py and make sure you properly set up the database connection params and you addons path location.May be it's better to leave the db_name to False so it will load all the features lazily when requested.

you can already see what happens if you:$ cd trunk-java-jython/bin$ jython openerp-server.py

You'll probably have errors because we didn't properly set up some required libraries.So it's time to copy paste a few libraries from our regular Python path to our Jython path:you can copy/paste the following directories:pychart, pytz, reportlabfrom/user/lib/python2.5/site-packages/ (or whatever you Python sys.path)to [...]/jython-dev/dist/Lib

There is one more catch though. Currently, there is bug in Jython preventing the reportlab lib to load fully. This is because font listings in the pdfbase/_fondata.py are just too large for the JVM spec to fit in a single Java method. The Jython folks are aware of that bug but it's low priority: see http://bugs.jython.org/issue527524Meanwhile, helped by the fellow Charles Headius Nutter from the JRuby Sun team who faced similar issues implementing JRuby, I patched the file to make reportlab works in Jython. It's only a wrapping of large list instantiations and doesn't remove any feature. I submitted it to the reportlab developers and hope to see it included waiting for a Jython fix.So in any case, for now, you should just move the _fontdata.py file provided in the trunk-java-jython branch and copy it in place of the reportlab/pdfbase/_fontdata.py file of your Jython reportlab installation.

So the GTK client can connect to the Jython powered server and list the available databases for instance.But if I try to really connect to the database and go further here I get an error unfortunately:

OK, enough said for now. I'll try to post updates on the dedicated Launchpad blueprint: https://blueprints.launchpad.net/openobject-server/+spec/jython-support-as-jython-improvesDon't hesitate to contact me if you want to push this work further.