[Gsoc] MI: port Zope 3 to Jython

Martijn Faassen faassen at startifact.com
Fri Mar 7 08:55:41 EST 2008


Hey,

On Fri, Mar 7, 2008 at 8:28 AM, Bernd Dorn <bernd.dorn at lovelysystems.com> wrote:
[snip]
>  i think this is an overhead that does not make sense, if we do this,
>  we have to support jython in the future, someone has to maintain this
>
>  what are the benefits?
>
>  -1 from me

I think there are some potential benefits:

* being able to run Zope on the java platform means we can make use of
a lot of java libraries. There is a lot of cool stuff out there.

* Zope on the Java platform takes away some of the interoperability
fears people may have. While Python is becoming more and more
accepted, Java's well established indeed.

* Spreading some of our basic technologies to Jython wouldn't hurt
their adoption (zope.interface, zope.component).

* Various alternative Python interpreters are around - Jython,
IronPython, the PyPy effort. We're bound to have to face the question
of running Zope on one of these alternate platforms at some point in
the future. This might be a good first step into non CPython land.

* In general such an announcement would indicate Zope is a player
here, which would help in marketing.

I think a project could be organized that aims for the ambitious end
goal (Zope 3 on the JVM), but realizes we'd likely not reach this in
one step, so has intermediaries that are useful. Some possible
intermediaries are:

* The hardest challenge would be to port various C libraries to JVM.
zope.interface to the JVM might be an interesting challenge. It's
possible these shouldn't be ported to Jython directly but to Java for
performance reasons.

* Of course the ZODB is probably the hardest challenge, and I don't
know whether it is possible right now. Just the research on what is
and what isn't possible would be, at least, of benefit to Jython if we
give feedback. Note that Lovely Systems is now able to use Zope 3
without the ZODB so it wouldn't be strictly necessary (though then
instead some relational object mapper would be necessary)

* To ensure maintenance, you'd need to have an infrastructure that
tests various packages on the JVM. This way people who break the JVM
tests can at least be informed. Building such a test infrastructure
should be part of the project.

Regards,

Martijn


More information about the Gsoc mailing list