crankycoder.com

…is one unholy trinity.

Jython’s gotten a lot of love lately, the 2.5 release is coming down the line quickly thanks to the work of Frank Wierzbicki and the rest of the Jython team.

If you haven’t grabbed it yet, go download it now.

Django on Jython is really almost there, but you should be prepared for a little bit of pain still if you’re going to adopt it at this point.  There’s a number of pain points that you’re going to bump into.

1. Jython has Java’s garbage collector, not reference counted garbage collection


2. CPython is deployed in a multi-process container where Jython is typically deployed in a multi-threaded container


3. Jython doesn’t have a lot of the C/C++ extensions that are wrapped up with CPython, so some libraries are just not going to work


4. pdb still breaks sometimes


5. Database drivers in JDBC land are abundant, but you may have problems with type coercion.

There’s niggly details that are different here and there, but those are the biggies.

So let’s go over them one by one.

1) Jython has Java’s garbage collector, not reference counted garbage collection

Java’s garbage collector is both awesome and horrible at the same time.  On the one hand, you’re buying yourself an excellent incremental garbage collector with Hotspot, but on the other – you’re losing the predictability of the refcount GC in CPython.

The tradeoff here is that lots of CPython code expects that garbage is immediately collected when reference counts go to zero.  That simply doesn’t happen in Java, so code that retains resources like say – database connections – may frequently leak when you port from CPython to Jython.

2) CPython is deployed in a multi-process container where Jython is typically deployed in a multi-threaded container

This one is similar to point 1), but a little trickier.

There’s small comments in the Django documentation like this one for DEBUG:

…

It is also important to remember that when running with DEBUG turned on, Django will remember every SQL query it executes. This is useful when you are debugging, but on a production server, it will rapidly consume memory.

Never deploy a site into production with DEBUG turned on.

Did you catch that?  Because in the 3+ years I’ve been using Django, I’ve never actually noticed that.  If you’re paying attention to deployment, you’re turning off DEBUG.  But hey – what happens when you’re not paying attention?  Well – if you’re running mod_prefork in your Apache configuration, your Python processes die.  So the memory gets cleaned up.  If you’re in Jython land with a long running never ending Java process – this never happens.

Mix in the general overhead of Java objects – and you quickly swamp gigabytes of memory really really fast.

3) Jython doesn’t have a lot of the C/C++ extensions that are wrapped up with CPython, so some libraries are just not going to work

You better not depend on scipy.  Or numpy.  On the other hand, you get access to a crapload of mature Java libraries which you’ll find both useful and annoying because of the general verbosity of Java.  Mmmm…factories of factories of abstract factories that read XML configuration.

4) pdb still breaks sometimes

I still haven’t been able to get a small useful testcase that will reproduce this, but I can pretty easily reproduce the error with Django.  pdb just kind of ‘loses focus’.  You can step up and down the call stack, but hitting “n” doens’t seem to actually go to the next statement.  Sometimes, pdb will throw an UnboundLocalException for no apparent reason.  If you’re interested in seeing this error and are willing to load up Django on Jython, give me a shout and I’ll happily point you to some Django code that will reproduce this error.

5) Database drivers in JDBC land are abundant, but you may have problems with type coercion.

For SQL Server 2000, I’m using the very nice jTDS package (see? sometimes all those java libraries are good).

For whatever reason though, you can’t use Statements.setObject(long) on database columns that are backed by BigInt types.  Or any other type.  This is probably something weird with jTDS but it reminds me of a lot of Java libraries where you’ve got these huge APIs defined for broad interfaces, but actual implementations may vary widely when you use them in real life.

Boo – it’s late.  More to come in the following days.

Next – adventures in forcing SQL Server 2000 to stop being a SQL92 hater,  how Dennis Gartman should really stop pretending to be a scientist, and why the words “force majeure” will be real popular for businesses to kill contracts in 2009.

Update:  More SQL2k fun with Django here