...

...

...

...

"MP" == Martijn Pieters <mj@antraciet.nl> writes:

MP> As for he C code, if you get Acquisition to work in Java, MP> you're halfway there. That is the hardest piece of Zope to MP> convert I think. There are some parallels to Acquisition already in JPython, although the ideas haven't been formalized or used to the extent they are in ExtensionClasses. I know JimH was aware of JimF's work here when he designed the mechanism, and it's something that I am quite interested in exploring with JPython. Essentially, when an attribute is found on a JPython object, a call is made to a method of the returned object, passing in the container of the object. In JPython the method is a Java method called _doget(), which can't be overridden in Python. From my understanding of Acquisition's basic model, _doget() plays the same role that __of__() plays. At some point, it would neat to standardize all this so things would work the same in JPython as in CPython/EC. _doget() is a key piece of the JPython machinery even apart from any Acquisition-y things it might be used for. -Barry

At 21:09 3-11-99 , Joe Grace wrote:

I could well be wrong. My vague recollection was that ZODB (or something else?) was licensed from someone outside DC for use only in Zope. I never really understood what the deal was, just that that chunk existed separately as a full-fledged product somewhere else. (Sound familiar to anyone?)

That's ZServer which is based on Medusa. But if you get far enough converting Zope to JPython, you'll be able to write a replacement. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | T: +31 35 7502100 F: +31 35 7502111 | mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ---------------------------------------------

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

At 12:12 PM 11/3/99 -0800, Joe Grace wrote:

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.

Some easier wins might be to: * Make a Java servlet that can funnel requests to Zope via PCGI or FastCGI * Make a Zope Product that can run servlets or other Java classes via JNI (there already exist some C-based interfaces to Java from Python) These could provide the desired Java interoperability without requiring a rewrite of Zope proper. Sure, it's not "100% Java", but as somebody else has pointed out, CPython can run pretty much anywhere Java can anyhow.

At 01:44 PM 11/4/99 -0500, Barry A. Warsaw wrote:

...

...

...

...

...

"PJE" == Phillip J Eby <pje@telecommunity.com> writes:

PJE> * Reflection: Zope makes heavy use of Python internals, such PJE> as function metadata

Newer versions of JPython have a lot of the reflection attributes expected from CPython objects. Not all of course, and I don't know what Zope requires, but e.g. func_code, func_globals, func_defaults are all readable. Some reflection attrs that are writable in CPython may not be writable in JPython. I'd be interested to know what Zope requires here.

Check out ZPublisher's "mapply.py" for what ZPublisher needs. Basically, it needs argument names in addition to the above, which if I recall from JPython's docs is not currently available (i.e. co_varnames).

PJE> and examination of bytecodes used in PJE> Python expressions.

Okay, that's a tricky one :)

Yep. The DTML "expr" logic scans Python bytecodes looking for ones which access a variable name, then looks them up in co_varnames to get the name. The purpose is so that names referenced in a Python expression can be "hotwired" into a locals() dictionary when the expression is executed. This is necessary because CPython can't deal with the locals() part of an eval/exec being anything other than a 'pure' C dictionary object. If JPython doesn't have this requirement for eval/exec, a workaround may be possible. I think there may be other bytecode hacking done in the DTML classes done for security purposes, but I don't recall off the top of my head.

PJE> * ExtensionClasses: ZPublisher and DTML are the only parts of PJE> Zope that can work without ExtensionClasses (and DTML PJE> performance suffers without the MultiMapping extension). PJE> ExtensionClasses are C-based Python types which override PJE> object behaviors in ways that Python objects cannot.

It actually might not be hard to "port" or re-implement ExtensionClasses to JPython, esp. because you've got a real OOP underneath. It might be as easy as deriving from PyObject, implement the behavior you want, and then exporting this into Python as a class that can be derived from.

I didn't say it was impossible, just that you need to deeply grok both systems. I'm one of (I believe) relatively few people outside DC who claim even moderate grokking of ExtensionClasses, so that would seem to imply that the potential number of people who could implement a port correctly pretty small. (Especially since I don't even have a rudimentary grokking of how JPython's underlying shells work.) Here are the things a JExtensionClasses would have to do, that I know of: * Implement the __of__ hook (from what you've said, this probably isn't excessively difficult) * Implement the __call_method__ hook (requires __of__, plus a "PythonMethod" helper class) * Impliment inherited_attribute (or whatever the exact name is) * Implement __class_init__ (called when an ExtensionClass subclass' class/type object is first created) * Allow hooking __getattr__ at a level above the level which is normally allowed by Python (i.e., *before* the instance or class dictionaries are searched) Hmmm. Y'know, now that I'm really thinking this through step by step... it doesn't look quite as impossible as it first appeared. However, my first reaction to that thought is that it probably just means my grok of ExtensionClasses themselves isn't as good as I think. :) Mainly though, it's occurring to me that a lot of the deepest voodoo I know of in ExtensionClasses has to do with making C subclassable in C or Python, and keeping track of reference counts. Since JPython already makes the underlying language subclassable, and doesn't *need* reference counts... Hm.

It would be a very useful discussion to have. I'd like to see much more convergence in the reflection and extension areas of the two implementations.

The interesting bit seems to be this: if the truly hard work of ExtensionClasses has already implicitly been done in JPython, it might make it more reasonable for somebody with a deep JPython knowledge to worm the necessary remaining ExtensionClass knowledge out of the DC folks or persons like myself. My interest in the project is rather limited, in that Java's not a buzzword I currently need for any of my work. But if it's doable, it'd be an interesting curiosity. Of course, once Zope itself is up, there are still things like intSet and BTree that have to be converted from C, as well as the cOptimizations, cPickleCache, etc. Which I expect will all have challenges of their own. In other words, "the devil is in the details."