Posted by: Arthur Blake | 2008-11-08

log4jdbc 1.2 alpha 1 released!

In this release, I’ve cleaned up the generated SQL a bit and added a bunch more options for controlling the SQL output. You can now turn on and off the type of SQL you want to log. For example, you might want to log only INSERT SQL statements and generate a SQL script from the logger output.

I also added an extra logger that shows whenever a new connection is opened, or a connection is closed. It also dumps all open connection numbers at each open and close event, so you can see how many connections your program uses as it progresses (great for detecting connections leaks!)

I reorganized the documentation to hopefully make things a little more clear, especially with the growing list of options.

The two most ofen requested features for log4jdbc are Maven support and DataSource support. I plan on getting these in before the 1.2 final is out. Please be patient!

For documentation and download, go to

Posted by: Arthur Blake | 2008-04-11

log4jdbc 1.1 released

log4jdbc is a little Java JDBC spy driver that I first open sourced about a year ago.

It can snoop on other JDBC drivers and log all the goodies going on with your database under the hood– SQL, timing info and more!

I just released the 1.1 final release today. It has some significant improvements over the 1.0 release which came out last year around this time. Most notably, it uses the SLF4J logging system (instead of log4j) so it’s much more portable as to which logging system you can use.

Hope you enjoy using it and please send me feedback if you like it (or hate it).

Posted by: Arthur Blake | 2008-03-02

CompressorRater 0.9.9 Updates

I’ve finally managed to find some time to work on the CompressorRater. Updates on line today:

  • The Packer compressor is now enabled. It’s still quite slow (because the Rhino JavaScript regular expression engine is slow) but I have a plan for how to make it really fast. Hopefully that will get done soon!
  • Updated Packer to 3.1 alpha 3 version.
  • Updated YUI compressor to version 2.3.5.
  • Slightly better look and feel.

Hope you enjoy! Feedback will be welcomed and appreciated.

Posted by: Arthur Blake | 2008-02-29

Happy Leap Year Day!

February 29 creeped up on me this year. I didn’t realize it was a leap year until just a couple of days ago! So I wanted to get a quick post in… since I won’t have another chance to post on this date for 4 years!

I’ve been heads down in coding up an enterprise Scheduler for a client, using the Quartz Scheduler library. Every time I have to deal with dates and times and time-zones, I am reminded how incredibly complex and bizarre the calendar system we use is–

It’s all just an elaborate construction to make sense of time in some kind of orderly way…

mind boggling

The passing of February 29 just reminds me how utterly imprecise our calendar system is. We have to add leap days every 4 years (except for even century years like the year 2000), and leap seconds are also added relatively frequently to further bring the wobbly rotation of the earth on it’s axis and it’s orbit around the sun into alignment with our calendar system. It’s mind boggling.

Do we even know when a leap second passes? Or does it all just get lost in the hustle and bustle… I was wondering that the other day. I had set my digital watch to a self adjusting clock (one of those clocks that keeps up with the supposed “real” time via radio signals.) I had checked the watch a week later and it was 5 seconds slow… Is my watch just slow… or did I miss a leap second or few?

Everyone counts down to zero on New Year’s day as if it’s some big singular moment, and yet each New Year actually happens at 24 (or more) distinct times on the earth.

Every time I have to deal with interpreting time zones and calculating date offsets across time zones, I get really confused for at least a little while.

There are so many rules based on political boundaries, local customs, daylight savings time and regional variations that it’s impossible to get it all straight across the planet. I’m really glad that libraries like the Java API and Joda time encapsulate most of the muck– or I’d REALLY be lost!

Once close-to-speed-of-light interstellar space travel becomes common and the mind warping effects of Time dilation come into play I’ll REALLY be lost!

Posted by: Arthur Blake | 2007-10-18

How do fixups work?

How do fixups work?

Straight JSON-RPC and even JSON don’t support or allow circular references.

Typical JSON parsers will cause a stack overflow as they recursively try to process the circular reference over and over again.

We have come up with a simple scheme that we use in jabsorb 1.2:

All circular references are detected and removed from the JSON before being transmitted over JSON-RPC.

An extra parameter is added to the JSON-RPC payload called “fixups”.
These “fixups” are simply a collection of assignment statements that “fix up” the circular references after the main JSON payload is assembled.

An example is perhaps worth 1000 words.

var simpleJson =
  project: "JSON-RPC-Java",
  year: 2005,
  site: ""

The above object does not contain any circular references and would be serialized by a typical JSON-RPC library like this:

  "id": 1,
  "method": "test.myTest",
      "project": "JSON-RPC-Java",
      "site": "",
      "year": 2005

Notice above that the outer, enclosing object is a JSON object itself, and contains several “meta” keys with information about the RPC being made. This is standard JSON-RPC stuff.

In this case, a procedure named “test.myTest” on the server is being called, and one parameter (our simpleJson object) is being passed as the payload.

Now suppose we construct another simple json object that has a reference to the first object.

var circJson =
  project: "jabsorb",
  year: 2007,
  site: "",
  parent: simpleJson

and then we create a circular reference like so:

simpleJson.myCircRef = circJson;

Now our simpleJson object would be serialized like this:

  "id": 1,
  "method": "test.myTest",
      "project": "JSON-RPC-Java",
      "year": 2005,
      "site": "",
        project: "jabsorb",
        year: 2007,
        site: ""

Notice that the circular reference was removed and replaced with a “fixup”. A fixup can be thought of as an assignment statement.

The “fixups” array contains all the fixup entries that should be applied to the JSON to recreate the circular references on the other side of the RPC call.

Each fixup contains 2 array elements itself. These are themselves arrays, containing the paths to the elements in question. The first path is the path to the element being fixed up and the second path is the path to the original element reference that is being applied to the fix up element. Together these can be thought of as like an assignment statement:

In the above example, [0,”myCircRef”,”parent”] is the “path” to where we want the fixup to be. It could be thought of conceptually as params[0].myCircRef.parent and the left hand side of the equation on an assignment statement.

And [0] is what is being assigned to this original path location. It could be thought of as params[0] and the right side of the assignment statement.

The reason this notation is used to specify paths is that it is extremely simple and fast for a processor to parse and execute these assignment statements in any language. Duplicate objects that are not necessarily circular references can also be passed via this mechanism to more faithfully reconstruct the original object, and can also potentially reduce the overall payload size if many duplicate objects are being passed.

Posted by: Arthur Blake | 2007-09-14

Announcing jabsorb, a new JSON-RPC library!

We are pleased to announce jabsorb, a new Java to JavaScript JSON-RPC library!

The project goal for jabsorb is to maintain (and hopefully improve) the practicality and beautiful simplicity that makes JSON-RPC-Java a great library, while also adding new common sense features, more test cases, and more documentation to make the library better for everyone.

jabsorb also aims to add more advanced ORB features, while maintaining complete backward compatibility to the JSON-RPC specification when these advanced features are not used. We are also going to submit some of these new features for consideration into the JSON-RPC specification itself (especially circular references support.)

jabsorb is a fork of the JSON-RPC-Java library.

Why are we forking?

1. JSON-RPC-Java has not had a release Since March 28, 2006 and that’s about a year and a half at the time of this writing.

In that time, some new changes and features have been checked into the CVS (and now SVN) trunk, but no official or unofficial releases have been made.

Many great ideas and suggestions have been posted to the mailing list, and it appears that many people are running on their own locally modified copies of the library– there doesn’t seem to be any cohesive strategy for getting the ideas into the library in a timely fashion.

jabsorb has been created to incorporate the best of these suggested features with a much tighter and faster build/release cycle.

We hope to have a new build released on the order of every 1 to 3 months.

2. We honestly don’t know where Michael Clark (the JSON-RPC-Java project lead) is, or what happened to him! We sincerely hope he is OK, but he has not responded to any posts on the mailing list for well over a month, nor has he responded to personal email regarding the direction of the library. There does not seem to be any other point of control of the library and it all appears to be underneath the corporate umbrella of metaparadigm.

jabsorb is hosted by google code with multiple owners.

Here are the new features that we will be releasing very shortly:

jabsorb 1.1 The goal of this release is to have a baseline that is a fork of the JSON-RPC-Java library we all know and love, with all the features from the latest unreleased SVN trunk from the parent library, along with some basic clean up and a few minor new useful features:

  1. Support for JSONObject and JSONArray raw serializers (this is an unreleased JSON-RPC-Java feature.)
  2. Support for SLF4J logging so that user’s may have a choice of the underlying Java Logging System (this is an unreleased JSON-RPC-Java feature.)
  3. Repackage code into org.jabsorb package space.
  4. Add much more Javadoc and comments in the code and clean up code style.
  5. Upgrade to latest library which has many bug fixes and nice features.
  6. Json pretty printing in DEBUG output (greatly aids debugging.)
  7. Optional GZIP compression integrated into JSONRpcServlet.
  8. Caching of list method calls for Callable References.
  9. More unit tests.

jabsorb 1.2 This release will introduce some significant new features:

  1. Circular References. This has been requested for quite some time, and we think we have a winner implementation!
  2. Security Policy. A flexible framework to better secure your server exposed objects and method.
  3. Constructors. A way to construct objects directly via json-rpc.
  4. JSONMap and JSONList. Alternative JSON containers with new serializers for simplifying the passing of Maps and Lists.
  5. Remote Map. Allows an array to have a server-side function called on each element with one request-response pair.

We are putting the finishing touched on the 1.1 release right now, and expect to have a build within the next week.

Some of the 1.2 features are done as well, and we are expecting to have the first 1.2 release build within a month after the 1.1 release, with a test release possibly even sooner.

Currently the jabsorb team consists of Arthur Blake and William Becker. Raziel Alvarez has shown some interest and minor commitment in contributing as well.

For the time being, I will be the self proclaimed benevolent dictator with William as a close backup.

We welcome ideas and input from anyone who wants to contribute. Contributions will be analyzed by the team, in the benevolent dictator style of open source project management.

UPDATE: jabsorb has re-merged with the original JSON-RPC-Java project (but retained the jabsorb name.) The project is now managed under an apache consensus style, with 3 team members on the commitee, Michael Clark, the original creator of JSON-RPC-Java, myself and William Becker. We think this will result in an even better library for the community, and I am excited about these changes. Stay tuned for a major new site and infrastructure roll-out.

Posted by: Arthur Blake | 2007-08-27

Compress Your JavaScript with the CompressorRater!

Ever wonder which JavaScript compressor you should use? Or which one can crunch your code down to the smallest size?

The “CompressorRater” allows you to easily play with several of the most popular freely available JavaScript Compressors on your own code, from one web interface.

You can quickly view how much compression all the tools give you both with and without gzip compression, and also view the compressed results directly.

You can also view some statistics of CompressorRater runs against the code in several popular JavaScript libraries. (Note that the compressed output of these libraries has not been tested and may not work. Before switching from a given sanctioned compressor on a given library, make sure you run through all the unit tests for that given library, using the compressed JavaScript!)

The following compression tools are rated:

  • JSMin is a conservative compressor, written several years ago by Douglas Crockford. It is considered safe (especially if you verify your code with JSLint first– an excellent thing to do anyway) because it doesn’t attempt to change any variable names.
  • Dojo shrinksafe is a very popular Java based JavaScript compressor that parses the JavaScript using the rhino library and crunches local variable names.
  • Packer by Dean Edwards, is also a very popular JavaScript compressor, that can go beyond regular compression and also add advanced on-the-fly decompression with a JavaScript runtime piece.
  • the YUI Compressor is a newer compressor written by Julien Lecomte, that aims to combine the safety of JSMin with the higher compression levels acheived by Dojo Shrinksafe. Like Dojo shrinksafe, it is written in Java and based on the rhino library.

When a given compression tool has options that you can set to tweak the compressed output, all possible combinations of options are run to show you the effects of the size differences when using those different options. Your compressed results are also viewable under all possible compressor options.

While this tool allows you to quickly test out the different Compressors, you must be sure to test your resultant compressed code diligently because JavaScript compressors aren’t perfect and can introduce subtle bugs.

Using JSLint to clean up your JavaScript code is always a great idea, and I’ve found that it can make your code work much better with any of the compressors.

I hope you find this tool useful! Check back often, because I plan to add some neat new features soon. I’m also looking forward to constructive criticism and comments on how I can improve the tool.

The CompressorRater is located at

Posted by: Arthur Blake | 2007-08-23

The CompressorRater

Ever since I discovered and started using JSMin a couple of years ago, I’ve wanted to see some hard numbers on how much savings can be gained by compressing JavaScript code. More recently, I’ve also started using dojo ShrinkSafe to compress some of my JavaScript code.

Lately with the introduction of a new compressor, the YUI compressor by Julien Lecomte, I’ve been inspired to write a tool to produce comprehensive compression statistics for a variety of popular compressors and also include a nice bar graph so you can easily see the compression levels visually.

I call this tool the “CompressorRater” because its primary function is to compare and rate JavaScript compressors. It can also let you view the compressed output, allowing you to use it as a general compression tool to compress your own JavaScript code.

If you’d like to take a sneak peak at the CompressorRater, it’s up here:

It currently has Packer compression disabled (unfortunately it runs too slowly for the time being– I believe it’s because regular expressions aren’t very efficient in Rhino.) I also tried running Packer right within the browser, and it’s just as slow.

I will very soon be posting the aggregated statistics and graphs for JavaScript code within various frameworks (such as YUI, Dojo, jQuery, etc.) These reports will include the Packer compression results as well!

I hope you enjoy using this tool, and I’d appreciate any feedback for improving it!

Posted by: Arthur Blake | 2007-08-20

Hiya, world!

Well, it’s about time that I had a blog… Why? What do I have to say? We’ll see in the upcoming days and months.


« Newer Posts