- What is JPython?
JPython is a new implementation of the Python programming
language which is designed to run on the Java(tm) Platform. It
consists of a compiler to compile Python source code down to Java
bytecodes which can run directly on a JVM, a set of support
libraries which are used by the compiled Java bytecodes, and extra
support to make it trivial to use Java packages from within
JPython.
- Is JPython the same language as Python?
We will always strive to ensure that JPython remains as
compatible with CPython as possible. Nevertheless, there are a
number of
differences
between the two implementations that are
unlikely to go away. These range from the trivial - JPython's
code objects don't have a co_code attribute because they don't
have any Python bytecodes; to the significant - JPython uses
Java's true garbage collection rather than Python's reference
counting scheme.
Python has never really had much of a language definition
beyond it's C-based implementation. The existence of JPython
changed that for the first time and will hopefully lead to a much
clearer sense of what Python the language is; independent of any
specific implementation.
We will be preparing a version of Python's regression test that
would be appropriate for new implementations of the language.
This is a good first step towards defining what parts of Python
are essential and which are incidental.
- What is the current status of JPython?
JPython 1.1rc1 was released on 21-Jan-2000, with the final
release expected before the
8th
International Python Conference. Check the
www.jpython.org site for the
most current release.
Jim Hugunin, JPython's author, has moved out to sunny
California to work on Xerox PARC's
AspectJ
language. JPython continues to be maintained by Barry Warsaw at
CNRI, with help and input from Python's author Guido van Rossum,
other CNRI folks, and the many contributors on the
JPython-Interest mailing list.
- JPython and Y2K
The standard response to queries about JPython's Y2K compliance
points you to the
Python FAQ entry on the subject, with the additional caveat
that JPython is of course dependent on any Y2K issues associated
with the underlying JVM and Java class libraries you're using.
However, you can essentially apply the Python Y2K stance to
JPython by, e.g. substituting the word "Java" for "C" in FAQ
question 4.65 (ignore the clip from the Python copyright
notice).
- What parts of the Python
library are supported?
The good news is that JPython now supports the large majority
of the standard Python library. The bad news is that this has
moved so rapidly, it's hard to keep the documentation up to
date.
Built-in modules (e.g. those that are written in C for CPython)
are a differnet story. These would have to be ported to Java, or
implemented with a JNI bridge in order to be used by JPython.
Some built-in modules have been ported to JPython, most notably
cStringIO, cPickle, struct, and binascii (donated by Finn Bock).
It is unlikely that JNI modules will be included in JPython proper
though.
If you want to use a standard Python module, just try importing
it. If it that works you're probably all set. You can also do a
dir() on the modules to check the list of functions it
implements.
If there is some standard Python module that you have a real
need for that doesn't work with JPython yet, please
send us mail.
- How fast is JPython?
At IPC-6
JimH reported speeds equal to CPython 1.4 on the pystone
benchmark. When Guido released CPython 1.5 he succeeded in making
it about 2x faster than the 1.4 release. The current release of
CPython is 1.5.2 which might be only slightly faster than 1.5.
JimH re-ran his benchmark tests against CPython 1.5 and his then
current release of JPython, finding that JPython was about 2.5x
slower than CPython 1.5. I have recently run a few informal
benchmarks and found some interesting numbers: using Sun's JDK
1.2.1 with JIT on a Solaris 2.6 Sparc Ultra 2, I found JPython
1.1beta3 to produce pystone numbers equal to (or very slightly
better than) CPython 1.5.2+.
The problem, of course, is that JITs are still not reliable
enough for JPython. Turning off the JIT on the above platform,
can slow JPython down by a factor of 10.
The speed of JPython is tied very tightly to the speed of the
underlying JVM. The benchmark results that JimH reported were all
using Microsoft's JVM from Internet Explorer 4.0. The next
fastest JVM that he used was almost a factor of 2 slower than
this. Since the performance of JVMs changes nearly every day, at
some point I'll need to collect a set of scores comparing pystone
performance on a wider variety of JVM's.
Finally, pystone is not the last word in benchmarking. At the
moment I'm more concerned with making JPython complete and correct
than with performance. We will continually be revisiting
performance issues both to examine better benchmark's for
comparing JPython and CPython (as well as other scripting
languages for the JVM) and work at optimizing JPython's
performance.
- Why do weird things sometimes happen in JPython?
More likely than not, the problem is with the JIT
(Just-in-time) compiler your JVM is using. JPython acts
like a bizarre Java compiler, taking Python source code and
emitting Java bytecode. It's bizarre because the emitted bytecode
doesn't look quite like the way bytecode would come out of a Java
compiler. JITs can sometimes get confused by this and will often
do incorrect and inexplicable things. If you're seeing strange
stuff happen, or weird bugs, the first thing to do is to turn off
your JIT and try again. If the bug still exists with the JIT
turned off then consider
submitting a bug report.
- Why did I get an OutOfMemoryError?
If you are using Sun's Java VM (or a derived VM) the virtual
machine sets a default memory limit of 16 MB. This can be very
confusing when you are running on a machine with 128 MB of RAM and
you see an OutOfMemoryError after having used only 17 MB.
You can increase this memory limit by adding the following
switch to the call that invokes the Java VM (you need to modify
the jpython launch script):
jre -mx32m <...>
This will set your upper memory limit to 32 MB. Obviously,
higher limits should be used if required by your program - and
supported by your computer..
- Why can't I use "from java import ..." on Windows?"
This problem can occur if you are using Microsoft's VM
(i.e. jview.exe) which provides the standard classes in a
different format. You need to run the following command in a
console window before using JPython:
clspack -auto
- Semantic Differences between JPython and CPython
There are several several differences between JPython and
CPython that wil probably never go away. These differences are
primarily related to underlying differences between the C and Java
programming languages/environments. See a more detailed list of these
differences. In brief though, here are two of the more obvious
differences you'll notice:
- JPython has true garbage collection - CPython uses
reference counting.
This means that in JPython users don't need to worry about
creating circular references as these are guarnteed to be
collected properly. On the other hand, users of JPython have
no guarantees of when an object will be finalized (short of
calling System.gc() to force garbage collection).
Theoretically, this might cause problems for users who were
depending on CPython's finalization timing to free limited
system resources. Also, because of the severe performance
hit when providing non-trivial Java finalize()
methods, no Python object's __del__() method is
ever called.
- Control-C can not be caught by JPython, but will exit the
shell completely
- Why can't I multiply inherit from two Java classes?
In an earlier version of JPython, you actually could. This was
deliberately disabled in 1.1 for a variety of good reasons. For a
detailed discussion on this issue see the following archive
messages:
http://www.python.org/pipermail/jpython-interest/1998-April/000213.html
http://www.python.org/pipermail/jpython-interest/1999-January/001162.html
Note that you can still multiply inherit from any number of
Python classes.
- Why does dir(someJavaObject) return the empty list?
Because the built-in dir() function returns
a list of names culled from the object's __dict__,
__methods__, and __members__ attributes. In
Python, an instance's methods live in the instance's class's
dictionary, so dir(someJavaObject.__class__) would return a list
of the method names (although only for the direct class, not for
any base classes).