Ahoy j.n'ers! It's been a while, but I had to come share a fun experience from the other night. Charles Oliver Nutter, one of the lead developers of JRuby, dropped in to the virtual world Second Life for a meeting of the Rubyists of Second Life. For an hour and a half or so, Charles, known in SL as Headius Exodus, shared the details of what JRuby is, why it matters to Java developers, and why it mattters to Ruby developers, too.

JRuby is a 100% Java implementation of the Ruby langauge that brings the power of a fantastic dynamically typed langauge into the Java enviroment, or the depth of Java libraries into Ruby.

The chat log and slides from the presentation are available at the RoSL website, Charles Oliver Nutter has a blog, and there should be a JRuby community here eventually:

  [19:15] Headius Exodus: We will probably get a Java.net blog/site up soon
  [19:15] Headius Exodus: they're leaning on us to do it :)

Share your JRuby experiences in the comments!

I started my programming life in Perl, and I am a lazy programmer. I get frustrated when I have to write duplicate code, or put information in more than one place. I'll search the web for days, try sample applications in 10 different frameworks, and write hundreds of lines of test code to find a solution that saves me half an hour. Now that's lazy.

I've been looking at persistence layers and frameworks lately. I don't like having SQL in my objects, partially because it makes things more brittle, and partially because I don't like writing SQL anywhere. I just want to write classes and instantiate objects, manipulate them for a while, and then have them stick around. I don't really care about the database itself. (In fact, most of the time I don't need a database, that's just a simple way to store stuff.)

I'm sure that somewhere there is a good list and comparison of available persistence layers, so I won't try to duplicate that here. What I will say is that almost everything I looked at required at least one of the following, and usually more than one:

• Extending a framework class
• Implementing a complex interface
• Writing XML mapping files
• Writing mapping classes
• Generating a database schema at compile time
• Code generation

Prevayler-style in-memory storage is kind of cool, but it also places restrictions on how you structure your client classes. I don't want restrictions, I don't want extra work, and I don't want duplicated code or information. How do I do it?

pBeans is one way. It really is as simple as I was looking for. Make some Beans, tag them with implements Persistent, make a store, and then put objects in the store and take them out. No SQL (one exception; read on), no XML, no mapping files. Free as in speech. Currently works with MySQL, Postgres, and SQL Server, and should be fairly easy to get working on other databases.

Here's how it works:

1. Create an instance of net.sourceforge.pbeans.data.GenericDataSource
2. Configure that DataSource with a JDBC driver and a database URL
3. Use that DataSource to get an instance of net.sourceforge.pbeans.Store
4. Create some JavaBeans
5. Call insert(), save(), delete(), and select() on the Store with those beans
6. Laugh at how easy it was to get your objects stored in the database

Well, mostly happy. JavaBeans make persistence easy, but violate another of my lazy principles: duplication. I can't stand writing getters and setters for every field. Java is already too verbose for my tastes, coming from a loose typing background. 2 copy-paste methods for every field is too much. Enter Groovy Beans.

Groovy is quite possibly the best thing I've encountered in the Java world, period. It makes writing for the Java platform enjoyable for me, and it really helps my wrists not hurt so much. Here's an example:

public class User {

    private Integer id;
    private String name;
    private String favoriteColor;

    public Integer getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public String getFavoriteColor() {
        return favoriteColor;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setFavoriteColor(String favoriteColor) {
        this.favoriteColor = favoriteColor;
    }

}

class User {
   Integer id
   String name
   String favoriteColor
}

import net.sourceforge.pbeans.data.*
import net.sourceforge.pbeans.*

dataSource = new GenericDataSource()
dataSource.setDriverClassName("com.mysql.jdbc.Driver")
dataSource.setUrl("jdbc:mysql://localhost/test?user=test&password=test")

store = new Store(dataSource)

class User implements Persistent {
    Integer id
    String name
    Integer age
    String hometown
}

joe = new User(name:"Joe User", age:43, hometown:"Bay Minette, AL")
store.insert(joe)
newjoe = store.selectSingle(User.class, "name", "Joe User")
assert newjoe.hometown == "Bay Minette, AL"

You'd think I would have found it sooner. If I didn't dislike PHP so much, I might have found it there. As it was, I only stumbled across it because a module I was using wouldn't work with Postgres's sequences, and as I was wading through the code, I saw it mentioned: SQLite.

So what is it? "SQLite is a C library that implements an embeddable SQL database engine. Programs that link with the SQLite library can have SQL database access without running a separate RDBMS process. ... SQLite is not a client library used to connect to a big database server. SQLite is the server. The SQLite library reads and writes directly to and from the database files on disk."

It's beautiful. It's simple. It's embeddable. There's a Java binding wih JDBC. And it's "two times faster than PostgreSQL and MySQL for many common operations."

It's not for everyone. The security is whatever the OS provides for files. It's not fully SQL92 complete (here's the list of what it doesn't do), even compared to MySQL. The locking is file-based and operates on the whole database.

Oh yeah, it's typeless. Want to shove some text in an int column? Go ahead. It's OK.

For simple apps that need to do a little SQL, but don't need all the bells and whistles, it's great. And for developers running local test cases all over, without wiping out production or semi-production databases, it could be a lifesaver.