if Jython follows JRuby, Jython might become the best Python platform, offering cross language implementation for OpenERP
JRuby proved the JVM is one of the best VM ever, being 3x to 5x faster than MRI C based Ruby. Now being also mostly faster than Ruby 1.9 which leverage the Yarv VM. Sun got the message and attempted the same for Python with Jython, recruiting the two Jython leads in 2008. Now Jython is improving very fast, not as fast as JRuby but taking the good bits of it. For instance ruby-ffi lead to some work that would make it easier to support C-Types in Jython. The same goes with the Invokedynamic JSR.
Also, Sun made JRuby what it is because of the Rails killer app. So I mean Tiny guys might perfectly send the signal to Sun Microsystem that OpenERP is THE Jython killer app they should port on Jython by all means. Then Jython might improve faster, just like JRuby.
Of course, by now, late 2008, Jython is not yet the best Python engine, so I speak more of an HUGE opportunity that should be preserved.
What would you gain by running on Jython?
1) Possibly a better Python implementation as I said, real multithreading and less memory use under huge loads (like Rails on JRuby). Better live remote monitoring using JMX...
2) One click installation on lots of hardwares
3) Penetration in large companies where Java tends to rule more than Python
4) Easier cross database support thanks to the unified JDBC API.
5) Larger community for OpenERP. OpenERP is certainly the open source ERP with the largest expert open source community. But just imagine how large it can be 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.
6) Possibly larger fundings 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.
7) 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.
But even better: Jython will implement 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.
Also notice the issue has been discussed there previously: http://
Raphaël Valyi.
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Raphaël Valyi - http://www.akretion.com
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Started
- Milestone target:
-
gsoc-2010
- Started by
- Raphaël Valyi - http://www.akretion.com
- Completed by
Related branches
Sprints
Whiteboard
Update 1: The recent move to psycopg2 certainly helps getting a JDBC data access wrapper on Jython. I've done some quick research and found that the psycopg2 lib expose a DB API 2.0 standard API, meaning that there is an official public API that could have other implementations. So far it seems that the zxJDBC lib is such a DB API 2.0 ibrary for Jython.
Have a look here:
http://
and also may be here:
http://
Update 2 - 17/01/2009: native library support in Jython are improving quickly now, elemtree seems to be there and pyexpat partially too, see this announcement:
http://
I think Jython is still slower than CPython, but on the compatibility side, it's not so far away. i guess when Django will get adopted on Jython more widely, it could make things even faster with a larger community.
Update3 - 26/01/2009: OK, I tried to hack the OpenERP to run it on Jython during a few hours.
Got Jython from SVN trunk:
$ svn co https:/
$ cd jython-dev
$ ant
after the Jython Java jar was built , I was able to start the server (still from the jython-dev directory) using:
./dist/bin/jython /home/rvalyi/
But there were a lot of errors of course.
So I disabled some stuff and wrapped others as much as possible. You can grab my patched version of OpenERP server trunk from my dedicated Jython branch:
bzr branch lp:~rvalyi/openobject-server/trunk-java-jython
The initial import is based on the openeerp-server trunk branch rev #1640
The patched code always comport the explicit "#TODO: JYTHON TEMPORARY HACK" mention
Basically: what was disabled:
- libxml, libxml2 and libxslt imports cause Jython can't use them directly. Of course that would break later on but we could use Xalan or other Java XML libs to wrapp around. After Jim Baker, libxml2 and libxslt should not be used. libxml which is at a higher level of abstraction should be used by Tiny. After him that wouldn't be slower. And he said that in the future libxml might be supported in Jython. Anyway, we can have our on wrappers for small things as we need them before that.
- the report system (pakages like render are not even imported)
- mx.DateTime has been wrapped around the standard datetime library from Python. That was put in an "mx" package to fake the eGenix API (involving C libs unfortunately). DateTime might work but RelativeDatetime might require more work as sugggested in the file.
- psycopg2 has been backed by zxJDBC (like in Django for Jython), so sql_db.py has been hacked quite a bit. The pool might still no close the connections properly, but it's properly firing the requests to Postgres and getting the answer.
Conclusion:
See update and how to get started here:
http://
NEW UPDATE 06/02/2009:
The following changeset (find why the hell it's not applied in stable branch) has been applied in Ubuntu 5.0.3 (backport) and fixes all the deprecated XML issues, that should RUN on Jython!
http://
Raphaël Valyi.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
