Re: [Jython-dev] Jython 2.1a3 on j2sdk1.4.0beta

[Joseph G. <oc...@se...>]

JZope (or Jope?) would be great and an obvious upgrade for zope, I believe.

I think Jope should be an opportunity for a speed upgrade since Java is
considerably faster than cpython.  jpython is slow because it can not use
java atomic (non-object) types for int's etc.  The python spec'n would have
to change to make that a possibility (at least while retaining 100%
compatibility with cpython).

Since this post, Zope Inc. has taken control of python development though,
so they have the ability to change both zope and python now.  There has also
been some very recent discussion on ExtensionClass work that could relate to
easing the port of zope to Java.  So that could be one fewer hurdles which
is good.  It's also good since it may reflect some interest by Zope Inc. in
the direction of a Jope.

On the down side, Zope Inc. has repeatedly expressed the perception (even at
the top levels) that Java is in *competitor* to Zope.  Nonsense to me when
the two technologies dovetail so nicely, but they perceive servlets and jsp
as weak-kneed competition for zope.  (Perhaps the ExtensionClass work is an
indication of a change of heart?)

In any case, the following quoted post is the meatiest overview of the
challenges of porting to java that I've seen on the lists since becoming
interested in zope a couple of years ago.  Unfortunately, I haven't used it
for over a year, so I'm no closer to understanding than the post itself, but
you may find it useful.  I would be interested in a jope or jzope.  :-)

= Joe =

From:  Joe Grace <oc...@se...>
11/3/99 12:12 PM
Subject: Re: [Zope] Java Port
CC: "zo...@zo..." <zo...@zo...>

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