Why Jython?
As programming languages go, Python is beautiful, elegant, fun, powerful, concise, and easy to learn. Python is written in C, but Jython is a version of Python that is written in Java. This means that you can write a program using Python, which has all of the niceness of Python, but also has access to class libraries that are available in Java. Remember, Java is both a language and a platform, which supports many other languages, including Ruby, Lua, and many others.
Python is popular, and widely used. It comes installed on the vast majority of popular Linux distributions. It runs on Windows. And, and the latest version of Jython not only allows you to use Java libraries, but it also allows you to use popular Python based frameworks like Django, a Python based alternative to Ruby on Rails.
The development of Jython is being undertaken by Sun, which bodes well for its future development.
Why DB4O?
After years of using databases any time I needed to persist information, I have finally rejected that appraoch. One day, will working with an elaborate library of objects that hid the database from programmers, I realized that it would be a lot less work if I could just persist the objects as-is. My code would look pretty well the same, but I would not have to maintain a web server or write stored procedures.
Less work is always a good thing, especially if you lose nothing in the process. DB4O is fast, and it saves objects to the file system – that’s just what I thought I needed. I looked at other products, but DB4O is the leader as far as I am concerned.
Why DB4O and Jython?
There are many reasons. One is that Jython allows you to write less code and to be more productive. Another is that it is not possible to use DB40 with Python unless you willing to use Jython.
Personally, I am attacted to the idea of using DB4O to persist objects with the Django framework. Django, an alternative to Ruby on Rails, will run on Jython. I do not anticipate being able to find the time to dig in to this problem. What would be required is an Active Record like wrapper around DB4O. I would be inclined to develop something that looks as much like Django’s data modelling framework as possible.
The first thing to be aware of is that DB4O persists Java objects, but it does not persist Python objects. Therefore, as you use DB4O with Jython, you need to define the classes you want to persist in Java. I usually put these classes in a JAR, and place them in my Jython classpath.
In an upcoming blog entry, I will use some of the DB4O samples and implement then in Jython. I will show you how to define the classes and create JARs using the Eclipse IDE. You can use Netbeans if you like, but I only have time to provide examples using the tools I commonly use.
Then I will show you how to use Jython to work with objects that have been persisted using DB4O. I hope to show you that you can do this in less time using Jython because you are writing less code. Where I can, I hope to showcase the features of Python that can make working with DB4O more fun.
Join In, If You Wish
If you become interested in these examples, please feel free to correct me or to offer better solutions. I will be sure to give you the credit. If you decide to extend Django for Jython using DB4O, I will participate where I can and provide whatever help I can. I can provide some space on a server for a web site, but you have many other options.

What Is Vendor Lock-in?
One of the worst things that could happen to you as a supplier of goods and services is for the customer to leave you for one of your competitors. You can prevent this by providing a service nobody else provides, by offering unrivaled quality or service, or by charging a price that is hard for others to match. You can also combine these methods of keeping a customer, and you can raise customer awareness by marketing and advertising your offering.
Another tactic is to find ways to prevent or discourage your client from switching even if he or she wants to. In other words, you can try to lock the client in. You can do this with service contracts that contain cancellation fees. Sometimes, a client locks him or herself by committing to a platform or product by writing code.
If I build my business on an in-house software solution that uses an Oracle database, I may do the work such that it is difficult and costly to switch to a different database product. If Oracle changes their terms of service, or raises the cost in some way, it may be cheaper for me to pay this cost or accept the service changes than it would be to change the application so that it works with a different database product. In this case, I have locked myself in.
If my needs are such that I can depend on the MySQL database, I am free to run my database on Linux, Windows, or some other operating system. My choice of MySQL does not lock me into using the Windows OS. However, if I want to use SQL Server, I will also need to buy a Windows license. Another way to lock you in is to provide products that depend on each other and to force clients to use one if they want to use the other.
Another way to lock you in has been to provide a software product that uses proprietary file formats or closed APIs. This makes it hard to switch to a new product without converting you old files, or rewriting your code. It is in your best interests to support open file formats, and open APIs.
For more information about vendor lock-in see:
Oppose Vendor Lock-in
Some people may argue that some of the practices I have described here are wrong or immoral. I won’t argue that. If you are willing to allow yourself to get locked in, then I suppose I will have to admit that the practices I describe are smart – I wouldn’t say the same thing about you.
As a consumer, you should want to preserve your ability to switch to a competing product. If something better than comes along, you want to be able to consider lowering your cost or improving the quality or performance of the software you use. In software, innovation is encouraged by openness and by collaboration more than it is by monopoly practices.
Defenestration is about putting you in the drivers seat. It is about encouraging innovation, choice and competition.
Why should we want LINQ for Java? A lot of the discussion in the LINQ for Java Google group centers on how to implement LINQ for Java. Here are some other considerations.
Some Background:
A long time ago, in a universe far away, I learned SQL. I also learned to write stored procedures, and I got pretty good at it. I was happy, and productive. When the tech meltdown happened, I was still in demand because I could work in the database, in the code and in the user interface. My clients were looking for a one-stop-shop.
In the years since, I have exposed myself to Hibernate, SQL Alchemy, PyTables, Berkeley DB, ZODB, DB4O, Active Record with Ruby on Rails and the Zend_Db part of the Zend Framework. I have not had a chance to work with each of these in depth, but I wanted to keep up with what was happening. I was impressed by each for different reasons, but my response to each technology was marked by a vague resistance. I was put off by having to learn a new way to talk to databases – I saw it as an improved means to an unimproved end.
But, The World of Data Has Changed:
Then I started to realize that the world of data is changing. In one project, I was using web services and a series of objects to exposed data to other developers. In another, I wrote an application that served data as JSON – not all of the data came from a relational database. In another project, I got to play with XQuery and an XML database. In another, I was dealing with GIS metadata, and files that were stored and associated with geographical locations.
Do you want to keep learning how to query and use data sources for the rest of your life? Or, would you rather leverage one skill which you already know? I know SQL. If I could use this skill, in a slightly modified form, to speak to relational databases, object stores, web services and many other data sources, I would be a happy man.
The world of data has changed. This has had the effect of broadening the required skill set we developers need to acquire. LINQ, in both the Java and and the .NET world, would narrow the required skill set. Imagine using the same syntax to talk to databases, objects stores, web services and even the file system. Imagine using LINQ to find books using the Amazon API. Or, imagine using any of a number of Google services using LINQ.
I might like not having to learn new frameworks, or having to understand the specifics of each API. I might want to be relieved of the burden of learning class libraries and interfaces. I would be more productive if I could use the same syntax over and over again.
Manager’s Point of View:
As a manager, I want the the members of my team to be productive. I do not want to burden them with complexity. I also want to be able to know which skill sets to look for when I am hiring. It would help me to know that the person I hired to work with objects that have been persisted using DB4O could use one set of skills to use a web service and talk to a relational database. My life would be easier. My training/learning costs would be lower.
In plain English, LINQ for Java is a good idea. The first question is not how. The first question is why.