Fourspaces.com

Feather Web Framework

Marcus R. Breese — Mon, 28 Apr 2008 20:35:21 GMT

I noticed that there was a new link on DZone today advertising a blogging engine for Ruby named "Feather". Well, I thought I'd take this opportunity to re-introduce my Java web framework named Feather. :) (Isn't name collision fun?)

(My) Feather is yet-another Java web framework. It isn't trying to take over the world, just the part of the world that uses Java and writes web apps. Oh, and the ones that want the web framework to do as little as possible. As such, Feather really only deals with the Controller aspects of an MVC web app (there are some utilities to help with the model and view, but they aren't required). I started it because I got frustrated with Struts and the 6 files I needed to edit to add a new action. It is used internally for a few applications, but is available under the Apache license.

The basic idea is that you don't need to extend an abstract class or implement an interface to create controllers for web apps. You write a plain java object that has normal methods. The methods are then wired up to incoming requests through regular expression @Path annotations. The methods can have any number of parameters that are auto-injected by Feather based upon request parameters, session attributes, etc... This is also configured using annotations. The only requirement for a Feather action is that the method must return a Feather Result object. This can send the user text, html, forward them to another URL, dispatch to a JSP page, etc...

The documentation is quite light (non-existant), but I'm more than willing to help anyone understand what is going on. Out of the box, it will work with Spring or Guice to build your controller objects, so you can inject anything that you want into your objects. You can create a fresh object for each request, or use a singleton for all requests. The easiest way to get started is to extend the FeatherFilter class, and add that to your web.xml file.

More information is available at http://feather.fourspaces.com

Why FeatherDB exists and why is it written in Java

Marcus R. Breese — Wed, 16 Apr 2008 19:50:21 GMT

Sorry about the formatting errors on some comments... they've been fixed (I think).

I think that I best addressed my lack of willingness to use Erlang here: http://reddit.com/info/6fvf1/comments/c03q623. Suffice it to say that my decision to rewrite the application was a little more complicated than my unwillingness to use Erlang.

So here I want to address a little better the differences between FeatherDB and CouchDB, and more importantly, where I think we go from here.

Data model

However, the biggest reason for the rewrite was that I didn't think that CouhcDB the data model quite right. I think that the ability to allow common attributes in documents is an important one. At least, it is for the application that I was planning on using it for. The use-case that I'm specifically thinking of is the ability to tag pages in a CMS. If you want to add a tag to a page, using CouchDB, you simply create a new revision of the document, and add the tag. Simple. But inefficient. You're effectively duplicating the contents of a document in the database to add common (meta) data to a document. The concept of a tag logically can apply to all revisions of a document, so there shouldn't be the need to create a duplicate.

(Note: This inefficiency only applies to the storing/retrieving of documents, running/creating views is a different issue, and I'm not quite sure how CouchDB would handle it) .

Java

Why is FeatherDB written in Java? Another way of saying this is why didn't I just work on the Erlang version? One reason was that I was primarily using a Windows machine for development at the time, and the development process for CouchDB (even to just get it running) was quite tortuous. I had to switch over to a Linux box just to write the Java library to connect to it. Why? Because I couldn't get the most up-to-date version running on Windows. This isn't necessarily a big deal for me, since I use a Windows, Mac and Linux machine on a daily basis. However, for some this is a deal-breaker. So, I wrote it in the language that I was working with at the time... it just happened to be Java.

Would there be the same issue had I written this in Python or Ruby?

Now, there is one big (and I mean big) advantage that Java brings to the table, and that is the ability to run multiple languages (including Javascript) in the JVM. This adds one feature that CouchDB cannot add without increasing overhead: the ability for a Javascript view to directly query the database. This feature allows for the ability to have 'joins' in your views. Meaning that the Javascript view function that you run can pull other documents from the database. This makes your view code much more flexible.

It is perfectly reasonable to argue that you may not want this feature, but I'm not sure how you'd do it with the current view system in CouchDB. Maybe it is possible, and I just don't know it.

Scalability

One of the biggest criticisms was the lack of distributed scalabilty of FeatherDB. My flippant reply was:

Re: Distributed - Via the plugin backend storage mechanism, it actually wouldn't be that hard to make the system distributed. There would need to be a new backend written that delegates requests to other servers. The trick is to figure out the logic to correctly 'guess' which server has the data you're interested in. However, this is entirely possible.

Now, this is admittedly a little simplistic. Writing a new backend to farm a single request to a number of other servers and then 'reduce' them back to return to the user isn't difficult. The pseudo-code is very similar to the in-memory-cache implementation that is currently in SVN. For a brute force, dumb system, it would work. What is difficult is figuring out what other servers to farm the request to. This is the secret sauce of any distributed system, and isn't trivial regardless of language. As was said by one of the commentors, there is no such thing as a simple distributed system. Perhaps this is were Erlang's sweet spot is... I don't know.

Unfortunately, from what I've seen, the simple distributed scalability that is advertised with CouchDB isn't quite a reality. But this is to be expected... CouchDB is very much a work in progress. People act as though it is a finished product, but this is far from the case.

Motivations

I think the bigger question is what are my motivations for writing this, and what are my motivations for releasing it to the public.

I love the things I read in Damien Katz's blog and his descriptions of CouchDB and non-RDBMS style of data management. I first heard of CouchDB from Assaf Arkin's blog, and I have continued to follow it ever since.

Now, I don't want to compete with CouchDB, and I'm not looking to make any money from this. I've released this because this is something that I worked on a few months ago, and felt bad seeing it sit in my private SVN repo gathering dust. That and, these are some concepts that I've been looking at for a while. I guess that my ideal outcome would be for some of these concepts to make their way into CouchDB so that I don't have to think about it. But, I'm more of a 'working-code wins' kind of guy. So I prototyped somethings up, and thought that maybe someone else could find it useful.

Future

I'm not too sure where FeatherDB will go. As I said, I'd be happy to use CouchDB (or maybe I'll have to look at StrokeDB or GrassyKnoll), but for now, it doesn't fit my needs. Until it does, I'll keep updating FeatherDB... and I'll be following CouchDB closely.

FeatherDB - Java JSON Document database

Marcus R. Breese — Fri, 11 Apr 2008 18:55:39 GMT

I've been holding onto this code for a while now (months)... I haven't finished polishing is, and chances are I won't. But there are a few important concepts in here that I think are important to get out into the open.

FeatherDB was my attempt at a Java clone of CouchDB. When I first found out about CouchDB, I was very intrigued. A non-relational database fits one of my projects perfectly... when you find yourself fighting with Hibernate just to get a schema mapped, there is an issue on one side or the other. In this case it was me. [I should note that I actually like relational databases for most things, it just so happens that my particular application doesn't map well to a static schema]

So, I did what any self-respecting geek would do - I downloaded the code and tried to get it running. And that led to the first problem: I was on a Windows machine and the (at the time) binary download for Windows washorribly out of date. Not to fear though, I had a linux box handy, so I just moved over to that machine. I downloaded CouchDB, and got it running. Then I had the problem that the java library wasn't compatible with the newer JSON syntax (the old version was all XML, all the time).
No problem there either... I spend a day or two getting my feet wet with the REST API, and wrote a new library couchdb4j.

Now, I was off and running working with CouchDB, and non-relational nirvana.

Or at least I should have been. At the time, CouchDB was (and is) very much a work in progress... there were a bunch of things that were planned but were missing, such as: support for stored/named views and any sort of authentication. No problem! I'll just add this myself!

Problem: CouchDB is written in Erlang.

I don't do Erlang.

I don't have anything against Erlang... we've never met. I just don't want to learn another language. Especially one that is so specialized. I know that I should learn a language a year, but Erlang was just too much of a hurdle for me to get in and start mucking around in code. Plus, would you really accept a patch from a guy that is just learning a language? Neither would I.

No problem! I'll write my own Java version of CouchDB... and do it better. The result was/is FeatherDB.

FeatherDB is a Java based document database. It has an all HTTP/REST interface. It supports querying by a Java class (added as a jar to the server), or via JavaScript (uses Java6's JavaScript support). In theory you could also search by any language that is on the JVM and implements the correct interface.

FeatherDB allows for flexibility in the backend storage, allowing you to use any backend you'd like. I wrote three: a filesystem based backend, an all-in-memory backend, and a caching backend that uses an in-memory hash and punts to a supporting backend when needed. (I'd like to add a BerkeleyDB or Derby backend to make things a bit more resilient).

FeatherDB uses an embedded Jetty HTTP server to handle all interaction.

There were a few things about the way CouchDB handles documents that I didn't like, so FeatherDB does things a little bit differently.

Like CouchDB:

Documents are accessed through the HTTP interface by a REST API.

Documents are versioned. Always. You can access any version of any document.

Document information is stored and retrieved in JSON format.

The Document space is "flat". Documents can link to other documents, but there is no concept of "joining" documents.

You query the database through 'views'. Views are also documents.

Unlike CouchDB (last I checked):

Access is controlled through an authentication layer.

Users are authenticated

though HTTP-Auth

or by loading /_auth?username=foo&password=bar

or via a previously generated 'token' (an authenticated user can generate a token, and pass it to an unauthenticated user for temporary access).

Users can be restricted to read-only, write-only, or read-write access to a database (document-level ACLs proved to be too slow).

Documents can have "common" data that is shared among all revisions.

Any attribute whose name starts with "_" is determined to be "common".

When you update that attribute, it is updated for all revisions.

This makes it trivial to support a feature like tagging, where you want to update all revisions of a document, including future versions.

Documents don't need to be JSON documents. A "document" in FeatherDB lingo is any file of any HTTP Content-type. This has a few nice side-effects. The FeatherDB server can now serve any type of file to any client. For example, you can upload a binary image to the server, load it in your browser, and it renders correctly!

No need to base64 encode a binary payload.

Content-types are determined from the HTTP Content-type header.

Everything is stored in binary format, unless the incoming HTTP Content-type has an associated handler.

So far, there are handlers for:

text/html

text/plain

application/javascript (JSON)

and image/{png,gif,jpeg}

Only JSON documents can be properly queried

A document's id can contain the '/' character. This means that you can 'fake' an HTTP server's paths by being creative with your document ids (Similar in this respect to Amazon's S3).

Because the content of a document is no longer JSON, there is the need for a "Meta-data" JSON file to accompany the main file. This meta-file is what stores the document's id, revision, etc... For JSON only documents, the JSON data is stored directly in the meta-data entry. For other documents, this is a separate file. Information in this meta-file can be dynamically added by the content-type handler. So, for example, the image handler can add width/height information to the record, and binary files can have their MD5/SHA1 sums calculated automatically on insert.

If you're keeping score, this means that using the default file-system backend, there are 2 files per revision for non-JSON documents, plus one more to store the common data.

The JavaScript views can query the database for associated documents. Okay, so this actually is like "joining" documents. Because the JavaScript engine is hosted in the same JVM, you can query the Java backend from the JavaScript view. This lets you create joined views of your data, if needed

Those are the major differences, and things that I think should be in CouchDB. As far as the status of FeatherDB, it has sat in SVN untouched for a few months, so I wanted to try and make it public, in case anyone else was interested. AFAIK, it works. However, there aren't any included libraries for accessing the server, so the API is a little undocumented. It does follow the CouchDB API as closely as possible though.

You can access the project via SVN at: http://svn.fourspaces.com/public/featherdb/trunk

If you are interested in more information about it, leave a comment, or send me an email at: mbreese at fourspaces dot com. Currently, the project requires Java 6 for the Scripting API support.

Getting started

Download the code via SVN from the above url

Run "ant run".

This starts the server with the default configuration:

Port: 8889

Admin username: sa

Admin passowrd:password

Backend: File system (directory "testdb")

Allow anonymous access

To access the server, connect to http://localhost:8889.
Important URIs

GET /_all_dbs -> list all databases

GET /_auth -> authenticate

You can authenticate via HTTP-Auth, or by passing the request parameters "username" and "password" (?username=sa&password=pass)

If anonymous access is enabled, all requests are treated as if authenticated as an administrator

GET /_invalidate -> invalidate the current credentials

GET /_sessions -> show active authenticated sessions (not in anonymous mode)

GET /_shutdown -> shutsdown the server (must be admin)

Databases

GET /{dbnme} -> db stats

PUT /{dbname} -> add a database (must be authenticated as admin)

DELETE /{dbname} -> remove a database (must be authenticated as admin)

Documents

GET /{dbname}/{documentid} -> Get the document's current revision

If this isn't found, but /db/docid/index is found, this will be returned instead

Optional parameters:

showMeta=true -> returns the meta-information for the document (see above)

showRevisions=true -> includes a list of available revisions in the meta-information

GET /{dbname}/{documentid}/{revision} -> Get the document's content (see above)

POST or PUT /{dbname}/{documentid} -> write the request's body as a new revision of the given document

If the documentid doesn't exist, it is created

POST /{dbname} -> write a new document, but use a generated id

DELETE /{dbname}/{documentid} -> delete the document (must be able to write to db)

Views
POST /{dbname}/_temp_view -> perform an adhoc query

The contents of the POST should be in the format of a javascript function

Ex:

function(doc) { if (doc.value=='foo') {map(doc.id,doc.value); }}

POST or PUT /{dbname}/viewname/functionname -> add/update a new view.

Note: the view name must start with an underscore ('_').

The default functionname is "default"

GET /{dbname}/_all_docs -> returns a list of all document ids

This actually calls an included view named "_all_docs"

Views can be either written in either Java or JavaScript. View documents are JSON documents that have the following attributes:
'view_type': 'application/javascript' or 'java:fully.qualified.class.Name'
Java views must implement the interface: com.fourspaces.featherdb.views.View
JavaScript views are implemented as JSON documents in the format:

 { 
'view_type': 'application/javascript',

'view1': function(doc) {
	// your code here
	if (doc.val='foo') {
		return doc; 
	} ,
'view2': function(doc) {
	// your code here
	if (doc.val='foo') {
		map('key',doc.val); 
	} 
} 
So, as you see, JavaScript views are functions that take a JavaScript object as input, and either returns a JSON object, or builds a map with a key and value. (See CouchDB docs for more information).

There is another associated JavaScript method that you can call, and that is: function get(id,rev,db). From JavaScript, you can retrieve other documents by id, revisions (optional), and database (optional).
Views are maintained by a "ViewRunner". The ViewRunner is responsible for maintaining the index of results for documents in the database. The only included ViewRunner doesn't store an index, but instead iterates over all of the documents in the database on each request.
Configuration
FeatherDB is configured by writing a "featherdb.properties" file. In the src/java/com/fourspaces/featherdb directory, there is a 'default.properties' file that shows the default properties and their values. Your featherdb.properties file will overwrite the default values.

Additional Notes
If you are using an access mechanism that doesn't support cookies, you'll need to pass a "token" with each authenticated access. This can be passed as a request parameter (?token=asdfasdf), or via an HTTP Header "FeatherDB-Token". The token is given to you when you access "/_auth". This isn't needed in anonymous access mode.

There is a severe lack of unit tests. I'm sorry :). Specifically, there is a lack of tests for running views, but it _should_ work.

I make no promises about this code. If it works for you, great. If not, let me know, and I'll see what I can do about it. As always, patches are gratefully accepted.

Future directions

I'm not sure what to do with this project. I'd prefer to not maintain a separate code base that may or may not track the CouchDB API. I'd personally like to see the changes in the document structures implemented in CouchDB, but I'm not sure if it is possible given the split in a document data and meta data. Then again, I'm completely unfamiliar with the CouchDB code base, so perhaps this will be possible.

I wanted to make this all public to see if anyone else may be interested in using this type of database and may be interested in helping to flesh it all out.

Hope you enjoy it!

Java Building Java

Marcus R. Breese — Sat, 16 Feb 2008 07:53:21 GMT

My last post was all about the problems inherent with using Java as a builder for Java programs. My conclusion was that it isn't a good idea... mainly because you have to solve a bootstrapping problem - you need to compile your builder before it can work.

Well, I thought about it a bit more, and figured, eh, what the hell? After all, working code wins. So, I sat around and attempted to make my own Java based Java builder. This ultimately turns out to be a two-step process:

Compile/package your builder
Call your builder with it's own classloader

So, how does it work?

You put your builder code in it's own source tree. I decided the "builder" folder would be a good choice. So, you put your builder's java source code in "builder/src", dependencies in "builder/lib", and your compiled code will end up in "builder/classes". My "Builder" class will compile everything in builder/src, and call whatever methods in one of your classes.

What?

Maybe it would help if I included an example... Here is how you build the builder:


java -cp builder.jar com.fourspaces.builder.Builder com.fourspaces.builder.BuilderBuilder
(or more simply)

java -jar builder.jar com.fourspaces.builder.BuilderBuilder

What this does is pretty simple: it uses the

com.fourspaces.builder.Builder

class to compile all the source code in "builder/src" and then calls the

@Default

task in

com.fourspaces.builder.BuilderBuilder

. In this case, the default task compiles the Builder project itself and creates the builder.jar file. You can call any method (that has no parameters) in the class that you call. So, for example, this will clean-up any artifacts from a previous build (clean method) and create the builder.jar (jar method):

java -jar builder.jar com.fourspaces.builder.BuilderBuilder clean jar

Not only can you call any method, you can also configure

@Depends

task-dependencies. So, in the above case, the "jar" task depends on "compile", which depends on "init". So, the methods that are called are (in order) clean, init, compile, jar.

The final little feature is that you can optionally create a single custom-builder jar file. If you do this, your command-line can be as simple as:

java -jar custom-builder.jar clean jar

Okay, so you can successfully create a bootstrapping builder in Java. Woohoo :) The real question is: is it worth it?

After much deliberation, I can say this: maybe. It doesn't suck as much as I thought it would, and you can really do some amazing things that you can't do in Ant. You can create whatever type of building infrastructure that you want without having to adapt your process to your build tool. The downside is that you have to do your own coding, so there isn't much already done for you.

As an example of what you can do, here is the BuilderBuilder class. I wrote three helper classes as well "JavaCompile", "JarBuilder", and "FileSupport". These helper tasks make compiling and jar building quite nice... from this code you can see how to define task dependencies, how to configure the default task, how to compile, how to jar up files, and how to do some basic file operations.

public class BuilderBuilder {

	private String srcDir = "src/java";
	private String buildDir = "build/classes";
	
	@Depends("init")
	public void compile() throws IOException {
		new JavaCompile()
			.setTarget(buildDir)
			.addSource(srcDir)
			.compile();
	}
	
	@Default
	@Depends("compile")
	public void jar() throws FileNotFoundException, IOException {
		new JarBuilder()
			.setFileName("builder.jar")
			.addSource(buildDir)
			.addInclude("**/*.class")
			.addSource(".")
			.addInclude("LICENSE")
			.setMainClass("com.fourspaces.builder.Builder")
			.create();
		
		FileSupport.copyFile("builder.jar","builder/lib/builder.jar");
	}
	
	public void init() {
		mkdirs(buildDir);
		mkdirs(srcDir);
	}

	public void clean() {
		deleteDir(buildDir);
	}
	public static void main(String[] args) throws SecurityException, NoSuchMethodException, IllegalArgumentException, IllegalAccessException, InvocationTargetException, ClassNotFoundException, FileNotFoundException, IOException {
		Builder.invokeBuilderTasks(new BuilderBuilder(),args);
	}
}

So, all in all, not bad. I'm curious to see if there is any interest in this builder. If there is, I'm interested in polishing things up a bit and making this project a bit bigger (and give it a name). I'm planning migrating my own projects over to this type of builder, so the built-in tasks will be pretty much centered around what I need. Specifically, the tasks that are on the list are: SVN update/commit, Javadoc generation, creating a WAR file, starting a Jetty container (using said WAR file), and JUnit testing. One other things that I'd like to add is integration with Maven/Ivy jar repositories. If you're interested in checking it out, you can check it out from SVN at: http://svn.fourspaces.com/public/javabuilder/trunk/

Note: it should be mentioned that this requires using Java 6, since it relies on the Java Compiler API. When running, you should make sure that you are using the "java" executable from the JDK and not the JRE (a common problem)

The problem with Java building Java (hint: it's Java)

Marcus R. Breese — Fri, 01 Feb 2008 07:49:28 GMT

I am very intrigued with the idea of new Java building infrastructure. I'm a pretty committed Ant devotee, owing to bad experiences with some early Maven builds. So far, there hasn't really been anything that I want to do that I can't get Ant to do. Every so often I needed to write a custom ant task, but that's pretty rare. However the main reason that I don't like Maven is that I'm a control freak. I like things in the directories that I want them. I don't like my project's build to the build tool. That just seems so counter-intuitive to me. But this post isn't about Maven...

Now, my needs are pretty simple: 1) setup directories, 2) compile classes, 3) run unit tests, 4) assemble jars/wars, 5) sometimes start/restart Tomcat. I don't deal with much inheritance simply because I don't need it. The few times I've tried, it ended up a giant sticky mess (that ultimately didn't work). My basic build directory setup is also pretty standard, so I can (for the most part) reuse a build.xml file from one project to another.

Even though Ant has served me well in the past, I have always had some uneasiness with the concept of using an XML "script". I've been slowly removing all XML configuration from my projects, opting instead for Annotations or DSL-style Java configuration (much like Guice). So, you could say that I've been in the market for an Ant replacement.

One top contender is Buildr. If you don't know, Buildr is a Ruby based build system for Java projects. (Such is the life of a polyglot). However, I've been holding off on trying Buildr until Ruby 1.9 comes out... I honestly don't have a good reason for not trying it...

Today I ended up reading about Gosling. Now this is an interesting idea that doesn't seem to be going anywhere (the last release was in January 2007). I starting to think about this a little more... why isn't there a Java based Java builder? I think this is a chicken and the egg problem. You need a builder to build the builder. And then it's even a little more complicated. You need a builder to build the builder so it can build your project.

Let's take a step back. What would the workflow look like for the developer? Well, if you're doing command-line builds (you can build all of your deliverables from a single command, right?) then you expect to be able to type a command and maybe an optional task. Such as:

make all

Even if you're doing some nifty bootstrapping, you're still looking at something like:

java -cp . Bootstrap Builder task

Now, if it were me I'd add a bash script to at least cover the java bootstrapping, so we're looking at something like

build.sh task

That's a little better. But, you still have to compile your project's builder.

So now instead of having one set of source code, you have two. Your project, and your project's builder. And if your builder requires libraries, you have two sets of dependencies (at least... your unit test may have their own as well). But, once your builder is compiled, you can finally compile your project.

java -cp builder/classes MyBuilder task

but that looks like crap (and takes too many keystrokes), so you'll have to write another shell/batch script. But at least we're getting somewhere.

This all seems very much like the saying "now you have two problems". I guess the point of this all is that while a Java based Java builder is an interesting idea, I'm not sure how much sense it makes. Look at the granddaddy of them all: make. Make exists largely to build C programs. Why not write a C builder in C? Well, then you'd have to first compile your builder...

(note to self: just try Buildr)

JavaCloth - Textile for Java (via JRuby)

Marcus R. Breese — Thu, 20 Sep 2007 04:47:44 GMT

This was quite the week for quick little projects for me. I'm gearing up to make a release of my web app framework (renamed from Scratch to avoid name-collision with the MIT project). It's now called Feather (http://feather.fourspaces.com), and as a bonus, I'm including a sample application as well... the Feather site source code itself.

Well, because I like making things more difficult than needed, the Feather web site is as close to being a wiki as possible without going full-out. Editing of the pages is done on the site. This means that I needed to either add a full WYSIWYG HTML editor, use a plain text box but hand-code HTML, stick with just plain text, or use another markup language. Well, I did what all the cool kids are doing... used the Textile markup language.

Textile is a fun little plain text code that allows you to use a simple set of markup rules to create HTML quickly. Unfortunately, the two Java libraries that performed the conversion are no longer maintained, and don't work for all the rules (tables in particular). So I did what any self-respecting hacker would do... started my own.

Now, after about 12 hours at this, I had a pretty good compiler design setup... it read in the files, and processed chunks step by step. But it wasn't done... I still had a few extra rules to support, and it was looking like some of my edge cases were going to be a bit difficult to tweak. (In retrospect, I should have used a state-machine concept or a compiler-compiler to just figure out the grammar and have it write the converter, but that's still a bit over my head).

Now, I mentioned the cool kids... how do they do it? Well, there is a little Ruby class called RedCloth that handles it. It's nice, easy to use, and more importantly works. So I decided to scrap my code and go the Ruby way... sort of. I quickly learned how to setup a JRuby instance, and embedded the redcloth.rb file... a few tweaks later, and I have a full Java textile parser. Only, it uses JRuby to actually do it.

I was pretty happy with the results, so I put it up on SourceForge: http://javacloth.sf.net. It only requires Java 1.5, since I didn't use the Java6 interface for JRuby... I might have to compile a different version for Java 6.

All in all, the JRuby code is quite easy to work with. Once you have an instance, you can just execute ruby code as you'd like... which makes it easy to setup the RedCloth class, and create a new instance to convert text on demand.

The main magic occurs in this bit of Ruby:

String script = 
"require 'java'\n" +
"class RTextilize < Java::"+JavaCloth.class.getPackage().getName()+".Textilize\n" + 
"	def textilize(txt)\n" +
"		RedCloth.new(txt).to_html.to_s\n"+
"	end\n" +
"end\n";
runtime.evalScript(script);

This creates a new Ruby class that extends the Java abstract class Textilize and implements its single abstract method

String textilize(String s)

. From here, you can get a handle on the object from Java like this:

Object rfj =  runtime.evalScript("RTextilize.new()");
Textilize rTextilize = (Textilize) JavaEmbedUtils.rubyToJava(runtime, 
(org.jruby.runtime.builtin.IRubyObject) rfj, 
Textilize.class);

And from here, you can call

rTextilize.textilize(String s)

all you want! Now, I ended up wrapping the entire thing up into a single JavaCloth class to handle all the Ruby initialization and RedCloth.rb loading, but I was quite impressed with what JRuby can handle and how easy it is to work with. All this in a single 4MB jar file (with all the dependencies included).

For more information on my library, check out the SoruceForge page: http://javacloth.sf.net

CouchDB4J

Marcus R. Breese — Sat, 15 Sep 2007 04:51:03 GMT

I added a new GoogleCode project today... so my limit is now down to 8. I don't know if you read much about CouchDB over the past few weeks, but it's a pretty interesting idea. Basically, it's the Document-centric framework that I've talked about before, but it uses JSON as it's data transfer language as opposed to XML/SOAP. It also operates using only REST style HTTP requests. The server is actually designed to operate at a very large scale across a grid to deal with queries in a Map/Reduce format.

Now, I've used about all the buzzwords that I'm allowed to use in one post, so I'll stop there.

I wanted to play with it, but my language of choice didn't have a good api that dealt with the newer CouchDB JSON style. 36 hours later, I have a new Google project that looks like it might work.

The API needs some cleaning up, but it's not too bad. Now I just need a project to dogfood it. Hmmm... a project that can dog food both a web framework and a document-base data store. What could that be?

Java versus Mac: User interface debate

Marcus R. Breese — Mon, 19 Feb 2007 18:54:47 GMT

I was reading this blog entry over at java.net this past weekend, and I tried to register for an account and sign in for the past two days just so that I could reply to this blog entry of Kirill's. Alas, java.net and I have issues, so I'll write my reply here.

There are a few issues with comparing NetBeans Matisse and Apple's Interface Builder (IB). The first off, is that each exists in their own ecosystems. Apple developers usually use Xcode and IB exclusively in designing their (Cocoa) applications. There are a few large counter examples, but for the most part, most developers use Apple's tools. Because of this, everything tends to conform to the Apple Human Interface Design specs. It's much easier to program a Mac Apple's way than to try to do it yourself. The expectation of Mac developers and users alike is that things will be done Apple's way, using Apple's APIs.

In Java, things are different. In Java-land, developers have different expectations because Java GUI programs live mainly on Windows and Linux boxes (okay, mainly Windows). However, since cross-platform ability is one of the main selling points of Java, we can treat Java programs as needing to work on Windows/Mac/Linux/Solaris (I threw in Solaris for fun). Additionally, most Java developers (at least the vocal ones), are very used to Apache-style open source access to common libraries. This means that Java developers expect open formats. They expect to be able to muck around with an XML file. They expect to not have binary/proprietary file formats describing things.

.Net/C#/Microsoft world is much closer to the Mac landscape from a developer's point of view. Microsoft has some of the best tooling in the industry. If you live and work in Visual Studio, you can expect that your programs will look and work like "Windows programs". Visual studio developers could care less about open formats... so long as it can be edited in Visual Studio, that's sufficient for most .Net/C# devs.

So the two main questions raised by Kirill are described by this comment by him:

elharo - i've raised two questions, and you didn't answer them. The first is - what tool besides Interface Builder can be used to operate on NIB files. If there is none, then the "locking" part of NetBeans argument is irrelevant. The second question concerned designed / intended use of each one of the tools (Interface Builder / NetBeans). As long as you stay in NetBeans (even if it means locking), what does it matter that it's split between two places? How would that get out of sync?

Of course, both questions are about Interface Builder against NetBeans, and not about NetBeans against other Java IDEs. My belief is that if you (as the developer) decide to use some IDE to visually operate on your UIs, you shouldn't complain about locking (JSR 198 is simply bound to fial {sic} miserably in such a dynamic and highly evolving field as Java IDEs). If you want interoperability and portability, don't use tools for your UIs.

To which, I answer Apple developers don't care about "locking". They are using a Mac for crying out loud. Macs are proprietary systems built upon an open source foundation. You are very much locked into the Apple design aesthetic if you are using a Mac. You can't compare the two development tools from this perspective. IB is the tool to design interfaces on a Mac. You don't have other options, and you wouldn't want them anyway because it didn't come from Apple.

Now, if you are in Java-land, you come in with a different set of expectations, largely due to the ecosystem that Java has fostered. Things are expected to be open. Things are expected to be XML configurable. Things are expected to work with multiple tools (because everything can read XML right?). It is ~~expected~~ demanded that a developer be able to view and change configurations of things by hand, if needed.

However, you can certainly compare the two approaches (IB and Matisse) from a structural standpoint. You might as well throw in Visual Studio into the mix as well (although, I'm less familiar with the newest version). I like the IB and Visual Studio technique of placing things in one location (regardless of the implementation of that store). I don't know why NetBeans has things repeated at the .form and source code levels. This just seems silly to me. As far as the argument that having a binary format lets the Matisse developers could change things quickly, why not just include a version tag in an XML config file? Then they could load a different handler for whatever version the file requested.

In my opinion, the main reason why Java is so ridiculed on the client side is that Java development tries to ignore the underlying operating system. It tries to hack on a look-and-feel to mimic the underlying operating system. There are definite up sides to this... however, there are very real downsides as well. If you try to be all things to all people, you can easily end up being nothing to no one. If, however, there was a way for Java GUIs to embrace the existing methods of the underlying operating systems to draw and design GUIs, then you may have something. However, if the java-cocoa bridge is any indication, then the validity of this approach has passed us by.

One reason why I don't like Ruby on Rails

Marcus R. Breese — Mon, 22 Jan 2007 08:02:35 GMT

I recently started playing with RoR again, just to see why it is so hot. I know one of the big pushes with Ruby is that it is very flexible and thus very fast to program in. Well, I don't really doubt that one bit. The only problem is, what if you don't know the language or the API for Rails that well.

It comes down to, "How do you learn the Rails API?". Or for that matter, how do you learn Ruby?

In the Java world, you have quite possibly the best IDE suites and toolsets ever made. (Well, I actually like Visual Studio quite a lot and it sets the bar quite high, but I don't do much C#/.NET programming). One of the benefits of having such a robust toolset is the ability to view the API on demand. Let's say you have a HashMap named "hashMap". If you don't know the API for a HashMap, all you have to do is dot your way through the API in Eclipse.

HashMap hashMap = new HashMap();
hashMap. opens a window will all the methods for the class. This is brilliant, and how I learned most of the Java I know. If you expect there to be some method to put something in the map... well, you can guess that it's name is something like "store", or "place" or "put".

Now for a complex API such as Rails, this type of completion would be nice, but due to the way that Ruby operates as a late typed/bound language, there isn't any way to really allow for this. Since you can dynamically change the signature for a class on the fly using mixins or proxies (I'm probably using the wrong words), you can never get the full API for a class at coding time. The only way would be to actually run the code, and then reflect though the class then.

So, how do you learn Rails? Websites, books, and videos. This isn't to say that it isn't worth learning, but it does make it a bit more difficult to learn how to do more advanced things without a lot of page flipping.

scratch - Google Code

Marcus R. Breese — Mon, 15 Jan 2007 07:24:05 GMT

The Scratch web app framework now has a new home. The project was originally hidden in the Fourspaces.com SVN server. Now, it has been let loose on the world, thanks to Google Code. This is the first project that I've hosted through Google Code, so we'll see how it all turns out.

The trunk version has been pretty stable for the past few months, so feel free to download it and try it out.