[Zope] Java Port

[Joe Grace]

Awesome post.  Thanks.  And ouch.

Sounds like heavy lifting.  That bytecode stuff sounds sticky (hadn't even heard
of that low a level of stuff before).  I still think its an obvious win, but I can
see where it may just be way hard.

Something (for me) to strive for as I come up to speed with Zope.

Thanks for the survey Phillip,

= Joe =


"Phillip J. Eby" wrote:

> 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.  :)