[Zope] Java Port

[Phillip J. Eby]

At 08:06 PM 11/2/99 -0800, Joe Grace wrote:
>
>Finally, on a coder side, there's been some discussion on this topic
>before.  DC has reflected on the subject and pointed out some
>non-trivialities of porting to Java (mainly (?) C code).  I imagine it's
>non-trivial, but getting something running might be reasonable.

Actually, no, it isn't.  The only part of Zope which might be 'reasonable'
is the ZPublisher bit, and even it makes heavy use of reflection (see
below).  Here are just a few of the things I'm aware of:

* Reflection: Zope makes heavy use of Python internals, such as function
metadata and examination of bytecodes used in Python expressions.  These
are not available in JPython, and it's not even a C issue, just a Python
implementation issue.  One reason some of these items don't exist in
JPython, is that JPython uses Java bytecodes, not Python bytecodes.
ZPublisher and DTML both use these reflection

* ExtensionClasses: ZPublisher and DTML are the only parts of Zope that can
work without ExtensionClasses (and DTML performance suffers without the
MultiMapping extension).  ExtensionClasses are C-based Python types which
override object behaviors in ways that Python objects cannot.  This means
that porting them to JPython means altering the JPython Java skeletons -
which will require good understanding of JPython internals, as well as an
*extremely* good understanding of the intent of the original C implementation.

* Persistence and synchronization: Zope object persistence and
synchronization are implemented via ExtensionClasses, and involve further
magic that will require very good understanding of the JPython skeletons as
well as the current C implementation for Zope.

* Acquisition: Actually, not as difficult, compared to ExtensionClasses as
a whole and persistence in particular, but it's still ExtensionClass based
and probably a fair bit of work to do right.

In short, if you want a "JZope", you're going to have to work mighty hard
for it.  Or...  if Pythons 1.6 through 2.0 move the ExtensionClass
machinery, or something like it, into the base definition of Python..  AND
the JPython folks follow suit...  AND Digital Creations moves to the new
"standard" extension machinery, THEN...  a JPython port might be (somewhat)
more "reasonable."

I thought the idea was pretty cool myself a while back, until I started
thinking about what it would actually take.  IMHO, it's too much work just
to get one extra buzzword added to Zope's already extensive collection of
them.  :)