Mark Watson's opinions on Java, Ruby, Lisp, AI, and the Semantic Web

Congrats to the Click team. My interest in doing Java web apps is low since I have mostly been using Rails for the last three years.

That said, Click hits a sweet spot with a good templating system and model super classes for pages, forms, tables, etc. Because I might be using Google AppEngine for more projects, I may need to use Java so I have just read through the documentation and code samples for the latest version that is compatible with AppEngine.

Labels: Java, web applications

I have been working on and off for 16 months on a book about Semantic Web (or Linked Data) application programming using the AllegroGraph product. I have decided to substantially increase the scope of this applications/tutorial style book to also include support for Sesame. The figure on the left shows the software architecture road map for the book using JVM languages.

I am splitting the book into two volumes, and using Latex makes this really easy to share small amounts of common material so both books stand on their own. Latex also makes it easy to combine both books into one all-inclusive book, eliminating the duplicated parts. The two volumes are:

• Volume I: will cover the use of both AllegroGraph and Sesame using JVM languages: Java, Scala, JRuby, and Clojure. I am working on a common wrapper written in Java that supplies my own (rather simple) API to both AllegroGraph and Sesame. My wrapper implements Sesame support for geolocation and free text indexing and search so the wrapper is adequate to run all of the book examples using either AllegroGraph or Sesame "back ends."
• Volume II: will cover only AllegroGraph using both the embedded and client Lisp APIs.

Both AllegroGraph and Sesame are great development tools, but fill different needs. On projects that can support a several thousand dollar a year per server license fee, I would choose Common Lisp + AllegroGraph for development. AllegroGraph is very scalable and the Lisp APIs are really nice to work with. For Java (or other JVM languages) applications, I would still choose AllegroGraph for the scalability and support if a project can support the license costs. The good thing is that for most small to medium size projects, the free version of AllegroGraph or the open source Sesame project both are good choices, so as a developer you have some real flexibility. There are also other good RDF data store platforms like Jena, Joseki, Kowari, Redland, 4store, Swi-Prolog Semantic Web library, Talis, Virtuoso, etc. but I have relatively little (or in some cases no) experience with these. I use AllegroGraph and Sesame so that is what I write about.

Labels: Clojure, Java, JRuby, Latex, Lisp, RDF, Scala, semantic web

This is good news! The lack of this plugin has been holding me back from upgrading from Eclipse 3.4 to 3.5. For me, working with the AppEngine platform has really put the fun back into doing Java development.

Labels: AppEngine, Java

The Mahoot project has just made their first public release of scalable machine learning tools for the Hadoop platform. With Amazon's Elastic MapReduce, it is possible (for example) to make an 8 server instance 1 hour run for about a dollar - combined with Mahoot, I think that this is really going to open the door for individuals and small organizations to more effectively use machine learning. Good stuff! I have started to take a quick look at the code but I won't have time to try it out on Elastic MapReduce for a few weeks (I am finishing the last Chapter of my Intelligent Scripting for Web 3.0 book and then I have some production work to do - so no free time for a while!)

It is interesting in life how things often come together just when you need them. I have a business idea that I want to pursue using EC2 and Mahout will probably help with a small part of the system.

Labels: AI, Java, machine learning

Very nice. I just installed the Eclipse plugin for the Java version of Google App Engine and created a new web app using JSPs and some static content. I have not yet tried using the JDO and JPA based Java persistence libraries (with Big Table being the underlying data store). The deployment was very easy. The application dashboard and administration web applications are well done and the people who wrote the Eclipse plugin did a very good job - really slick.

With free pricing for low volume web applications and moderate pricing once you go over the free quotas, I would bet that a lot of Java developers will jump off of higher priced Java web app hosting services. For my own use, it is an open question how much I will use this service. I really enjoy configuring Linux servers, installing just what I need. I lease two Linux servers for running Rails and Java web apps for customers, my own stuff, and general experimenting and fun. App Engine may be too "abstracted" of an environment for me - I may change my mind if it is easy to:

• Use BigTable via JDO or JPA
• Easy to assign my own domains to App Engine web apps (I am sure that it will be)
• That response is good (the admin web application provides statistics to measure this)
• It is easy to upload data into BigTable, and export it

Although I base a lot of my daily work flow around various Google services, I always do like to feel that I am not locked in. For example, I like that it is very easy to backup my GMail and Google Documents to my laptop. So far, I don't see why Java web applications can not be written in a portable way making it easy to run on either App Engine or my own servers.

I don't even know where to begin comparing App Engine with Amazon's EC2 because I see using them for rather different purposes. I have a lot of learning curve time invested in EC2, S3, etc. and no time at all using the Java version of App Engine but hopefully in a month or two I can make an informed comparison. Using EC2 seems closer to the metal in the sense that you need to design an architecture that deals with failing server resources. My first impression is that App Engine abstracts away handling failures at the application level - a benefit, but with a loss of flexibility. So EC2, for me, has more of a "build it myself" feeling. If you enjoy hacking/configuring Linux then EC2 would seem to be your best bet.

Labels: Google, Java

I am within a month or so of completing the third edition of my book. This book will always be available as a free PDF from my web site and as an instant-print book.

I would very much appreciate technical feedback on the manuscript which can be downloaded from my open content page: www.markwatson.com/opencontent/

A direct download link is: www.markwatson.com/opencontent/JavaAI3rd.pdf

Thanks in advance!

Labels: AI, Java, technical writing

I just released a new version of my KBtextmaster Natural Language Processing (NLP) Java library. Free for non-commercial use, with a small fee for commercial use. Should also work fine with JRuby :-)

Labels: AI, commercial products, Java, NLP

Although there are several Semantic Web libraries or frameworks that I like to use, I had to choose just one for a DevX article that I am finishing up. I chose to use Sesame. After covering what I think are some "big wins" of using RDF/RDFs/OWL (for some applications) I present some example programs that I hope that readers have lots of fun with. The "wrapper" library that I wrote for Sesame works fine for both Java (which Sesame is written in) and JRuby. I must say that for experimenting with Sesame, JRuby is a lot nicer because the example programs are much shorter and with Ruby duck typing it is easier to write callback handlers, etc. for my wrapper library. Being able to work interactively in a JRuby jirb shell is also a big win for experimenting with code, different SPARQL queries, etc.

Labels: Java, RDF, Ruby, semantic web

Several years ago I did a few projects for the "Java cell phone" (J2ME) platform, and had a lot of fun with that.

After recently setting up NetBeans with the Java ME CDC tools and Eclipse with the most recent Android platform tools, late last night and early this morning I installed Apple's latest developer's tools that include the iPhone SDK and Dashcode. Since I very much like my Nokia N800, I am also interested in medium resolution devices (the N800 has a good 800x480 screen).

My interest is in writing web portals that support both browsers and small devices. One option is just creating special CSS for different web browser screen sizes, and another option is rendering page view data as XML or JSON and letting rich clients provide the display and handling of forms, etc. (an option I used several years ago on a customer project).

Ideally, I would like to be able to support a wide variety of small devices without a very large investment in my time getting (back) up to speed. I have just a little experience with Objective-C and Cocoa so for the iPhone, just using Dashcode looks like a good option (for me).

Labels: Java

Last February, I wrote a AI blog article on a very simple Ruby library to parse some relationship values returned by the Open Calais web service. I wanted the same functionality today in a Java program. I was surprised that the number of lines of code required was the same - strange since Ruby is a much more concise language than Java.

The trick was that I was able to point my NetBeans IDE at the WSDL file for the Open Calais web service, and the work of calling the web service was essentially done. The Java code for parsing what I wanted out of the returned result was a little longer than the Ruby code, so the two programs ended up being the same length.

Another example of a time saver for Java vs. dynamic languages like Ruby, Python, and Lisp: using a Java IDE (like NetBeans) to generate unit test stubs from any application class - not so good for test first development, but I don't do that: I like to make a first cut at implementing classes, then add unit tests. While the Domain Specific Language (DSL) Ruby on Rails does generate test stubs, they are not as complete or useful as what NetBeans generates for me.

Lastly, because Java is a statically typed language, Java IDEs still do a better job at refactoring, code completion, etc. than environments for dynamic languages although Emacs based Lisp development tools and the Ruby NetBeans tools are very good.

Labels: Java

I have been working on packaging some of my (mostly) research code into four libraries (a picture), three that depend on a forth.

My concern is mostly "Java IDE kung-fu": users of these libraries (mostly just me :-) only want the highest level APIs to show in popup completion lists and the entire set of implementation classes remain invisible. The solution is easy: a public API class with implementation classes in the same package with package-ony (i.e., neither public or private) visibility.

Labels: Java

Authors David Salter and Frank Jennings have written a very targeted book specifically for enterprise developers wanting to use NetBeans with the SOA plugins.

Service Oriented Architecture (SOA) can be loosely described as implementing business processes by combining web service calls to available services. Just as you would probably not want to perform database operations without transactions, when you combine web service calls for specific business processes you want to wrap them in transactions and using BPEL (Business Process Execution Language) modules makes it easier to express logic and error handling. The BPEL designer plugin lets you work with a graphical interface and avoid tedious hand editing of XML files.

Just like using full J2EE stack adds a lot of complexity, with attendant benefits, to large scale Java server side development, SOA also adds a lot of "baggage" to building systems using web services, but as systems become larger and more complicated that structure can really pay off.

There are no magic bullets in software design and development that remove the requirement for hard work in analyzing system requirements and iteratively work on design and staged prototypes: for SOA applications you need to understand your business processes, what events can occur, and what error conditions need to be handled. If you don't understand these basics, no framework is likely to save a project. If you do understand these basics, and you want to use Java SOA frameworks and tools, then this book is a good guide to getting started. I do have a few minor complaints about this book: figures are not numbered (perhaps not such a bad idea, I am just used to seeing figures identified) and there is sometimes too much detail given for some developers: the reader is carefully led through setup, using the IDE plugins specific to SOA (BPEL builder, WSDL and XML Schema editors, etc.) and sample applications with many screen shots. Even with these small complaints, this highly targeted book should be very useful to Java developers looking to develop SOA applications. It would be best if readers already had at least a little knowledge of SOA, BPEL, etc. since this book mostly covers using the tools in NetBeans to facilitate build SOA applications.

Labels: J2EE, Java, SOA

I earned my living between 1988 and 1997 developing and being a mentor using C++. I usually argue against using C++, a language that offers superb runtime performance (speed and memory utilization) with the penalty of greatly increased development costs.

For most applications, it is less expensive to optimize for developer productivity. In my decade of using C++, with hindsight, the only projects that needed the performance of C++ were a commercial product for Windows 1.03, some VR work for SAIC and Disney, work on two Nintendo video games, a real time expert system for PacBell, and a PC racing game. All other C++ projects could have been done with more economy and effectiveness using other languages.

I used to error on the side of staying current with too many programming languages, although in the last few years I have invested heavy time in only three: Ruby, Java, and Common Lisp. Even though I find C++ development to be less fun, slow, and sometimes even a little painful, I am considering replacing Common Lisp with C++ in my small set of 3 languages that I am willing to invest heavily in. This Benchmark game of C++ vs. SBCL Lisp is one reason for this (possible) decision. The other reason is that I find Ruby to also be very good for quick prototyping and fast agile development, and even though the runtime performance of Ruby is very poor, it seems like the combination of Ruby + Java + C++ covers a wider range of application development than the combination of Ruby + Java + Lisp. In other words: Ruby gives me a lot of what Lisp does and I feel like I need one agile scripting language in my programming language toolbox.

Sure, "the best tool for the job", but I like to also consider the costs of not totally mastering the tools that I use in my work. This is why I have given up (for serious work) some great programming languages like Python, Smalltalk, C#, and Prolog.

Labels: C++, Java, Lisp, Ruby

Although I have been paid to work on both the Enhydra Enterprise Java application server and on the JBoss based Jaffa framework, I must admit that Tomcat has always been my favorite platform: lean, and add just what I need.

As a result of my 'build up just what I need' preferences, I just got around to experimenting with Glassfish. The Update Center is great, and as more instant install frameworks and applications become available, this will be a time saver. The web admin tool is refined - no complaints there.

I do have one complaint about the 200 MB resident memory footprint. A lot of what I do involves deploying to low cost servers, often semi-managed VPS systems. Smaller memory use is cheaper, but for most large server deployments, an extra 100 MB makes no difference.

I thought that it was very cool that one of the available instant install components is JRuby with the most excellent Goldspike. I have written before in this blog about the ease of running Rails web apps with Goldspike and JBoss. With Glassfish and the Update Center, it is even easier. Cool stuff.

Labels: J2EE, Java, JRuby

In the 1970s, I very much enjoyed working through Jean Sammet's classic book "PROGRAMMING LANGUAGES: History and Fundamentals". For one thing, it was my first real exposure to Lisp, and it was fun learning many new languages at once. At one point I had over a dozen programming languages on my resume (due to needing to use some one-off languages for military hardware, and several different assembler languages).

Generalization is good because the more experience with different languages, libraries, frameworks, and development styles that you have, then the easier it is to choose a good technology to solve new problems. I would argue that broad experience is at least a little better than narrow but deep experience.

Unfortunately there is another side to this issue: whenever I see really great design and code, it almost always seems to be written by someone who deeply specializes in one, or perhaps two, programming languages.

In the last few years, due to customer requirements, I have had to work in Java, Common Lisp, Ruby, and Python (and a little work with Prolog, and even less fortunately in C++). I am now in my mid-50s, and semi-retired (I try to limit myself to working no more than 25 hours per week). I would like to specialize in just one or two languages and not have the overhead of staying current with a half dozen programming languages.

The language that I enjoy the most is Ruby, and with the maturation of JRuby, it is great to be able to use the same language for scripting and general software development (using Matz's C based Ruby) and when I need to use existing Java libraries and frameworks (JRuby). While I really enjoy Lisp and Smalltalk (never professionally), my hope is that as JRuby continues to get faster and integration with the Java platform improves that the combination of (C or J)Ruby and Java will cover everything that I need for my work. BTW, the comment about future work on a "compiler that allows compiling a given Ruby class 1:1 to a Java class, producing a class you can construct, with specific signatures you can call from Java code" posted by Charles Nutter a few days ago to my JRuby blog article was very good news indeed.

Labels: Java, Lisp, Ruby

Pardon me for playing with the title of Edsger Dijkstra's famous paper, but as a Java developer I am starting to believe that arrays should be seldom used, given Java generics and the revised collection classes. I started thinking about this while reading someone else's code and noticing some artificial looking conversions between arrays and collections. Then for fun, I did some measurement and noticed over 15% of processing time was spent in toArray() methods.

The big cost in IT is usually in development and maintenance, not in deployment costs. Most projects are small, not Amazon size deployments so I believe that unless you are sure that you are building a very large scale system, it is best to optimize development to reduce costs for small and medium size systems. Smaller code size means smaller costs. Java programs should be as short and concise as possible and generics and use of collections helps a lot. Sometimes when I read the source for Java programs it looks like the authors were paid by line of code :-)

Labels: Java

Based on experience with consulting jobs developing web applications using several Java frameworks, Ruby on Rails, and Portable AllegroServe with WebActions (open source Common Lisp frameworks), I believe that choice of framework is less important than:

• Programming language: choose a language that both fits the application domain and has good library support for your application
• Data modeling: while I believe in interactive bottom up development, spending time up front getting object models 'right' makes development easier
• Object persistence: there are lots of good choices (prevalence, object relational mapping for relational databases, distributed memory only, etc.) but choose a scheme that makes sense both for development and deployment

I think that these 3 issues are all more important than choosing a web UI framework.

I have been investing a fair amount of time learning Erlang this year and the ErlyWeb framework (that uses the high performance Yaws Erlang web server) looks very good for both interactive development and distributed deployment. For web applications that map well to Erlang, ErlyWeb allows Erlang to be the development language of choice, but again the important choice is programming language selection rather than web framework.

Labels: Erlang, Java, Lisp, Ruby, web applications

Although most of my work is in AI development and general web services, I greatly enjoy writing user interfaces - this interest started in 1982 when SAIC bought me a Xerox 1108 Lisp Machine - the windowing system and general development tools were so good that they make most recent software development environments look weak.

Google Web Toolkit (GWT) and Squeak Smalltalk based Seaside are pleasant exceptions. Just like using Rails, GWT and Seaside provide that pleasant "everything just works" experience and great interactive development environments.

Last night I used GWT and IntelliJ to prototype some web UI ideas. If you have not tried working with the GWT Development Shell, give it a try: changes to client side resources (style sheets and HTML) and to Java client side source code (automatically compiled to Javascript during development) are immediately reflected in the test web app. I don't have any current tasks dealing with Java web applications right now, but the next time I do, GWT looks like a very good framework choice.

Seaside also supports the same fluid interactive development style: changes made in a Squeak Smalltalk source browser are immediately reflected in running web application. Seaside uses continuations to provide a more linear programming model. Blocks of code are used instead of URLs; inside a code block, you can call another code block - after a "return", you continue where you left off in the first code block. There is a performance penalty for using continuations, but it looks straight forward to run multiple Squeak processes behind Apache so it look like Seaside scales the same way that Rails scales. DabbleDB is written using Seaside - a great proof of concept for scaling.

Labels: Java, Smalltalk

Here is the download link. These tools come in a few 'flavors': Java, Ruby, C++, and C#. I expect to add two larger NLP projects in the next month.

BTW, I consider the LGPL to be "business friendly". You are allowed to mix my LGPL software with your own commercial products without open sourcing your products. You may also mix my LGPL software with open source with projects with Apache, BSD, MIT, or Mozilla style licenses. If you have any questions, ask me. If the LGPL license prevents you from using this material, please let me know about it.

Labels: AI, C#, C++, Java, Ruby

I dislike re-writing code that works well without a very good reason. Sometimes there is a temptation to rewrite code in order to move to a new language and platform. The Quercus PHP run time WAR file from Caucho looks like a good way to mix and match existing server side Java and PHP projects. Several years ago, a customer asked me to loosely integrate (just share a common login) SugarCRM and the JSP+POJO+Prevayler based web app that I had written for them to manage their research papers and devliverables. Not difficult to do, but my integration solution was a hack. Compiling PHP to byte code for the Java platform and easier (non-web service) calls between PHP and Java is an obvious win for developers. When JRuby's performance gets better (and it will :-) I look forward to the same type of integration with both Ruby and Rails.

Labels: Java, Ruby

As a developer, I have spent about equal time the last few years doing paid-for work in three programming languages: Common Lisp, Ruby, and Java. As you would expect, I try to apply the same tools and ideas for all three languages. This helps prevent the small "mental overhead" when switching languages. After reading the Guice User's Guide while having lunch today, I believe that I am going to use Guice for one or two of my "personal time" projects in order to try it out and add it to my toolkit.

The question that interests me is: how to use Guice patterns in dynamic languages like Common Lisp and Ruby? For Common Lisp, I recently started studying the project Closer - a wrapper for smaller projects for AOP and uniform interfaces (and enhancements) for MOP and context oriented programming. Good stuff!

For Ruby, there are a few projects for injection of control (e.g., Needle).

I am not sure how well spreading this pattern over three programming languages will work for me, but it makes sense to put some effort into consistency.

Labels: Java, Lisp, Ruby

I spent 20 minutes this morning going through the struts 2 examples and browsing the demo source code. Good stuff, but I am going to sick with my minimalist JSP + POJO + CSS + AJAX supporting Javascript tool kits for most applications. If I need to do anything complex, I will choose between 2 great frameworks: OpenLazlo or GWT. I have also taken a careful look at Flex 2 - another great toolkit but I like OpenLazlo's support for both Flash and DHTML.

Another picture (one block from our house at our local hiking trail head - taken a month ago):

Labels: Java

Ergonomics is the study of human capabilities in relationship to work demands. There are a few aspects of the Java language that tend to make programmers less effective than developers who use concise scripting languages like Ruby or languages like Lisp that enable the development of new domain specific languages on top of the Lisp language. I would like to address two techniques that I use to make Java development more ergonomic, given the limitations of Java.

Fixable problem #1 for me is that Java is not a concise language: I believe that the fewer lines of code in a project, then the easier to read, understand and maintain. I try to crunch down the size of my code by writing getters/setters on one line and initializing multiple variables per line. Also, since most laptop and desktop displays are now a wide screen format, I tend to use more "horizontal real estate" when editing - try to maximize the code that I can see on one screen by putting some small code blocks on one line, etc. - but be careful to keep code readable.

Fixable problem #2: application size and complexity: I always prefer to chop projects up into sub projects. Modules can be tested in isolation and then generate JAR files for use in larger aggregate projects. Including source code in your JAR files makes them more Java IDE friendly for reading library code.

The non-dynamic nature of Java does have one large advantage: IDEs like IntelliJ and Eclipse can offer better auto completion and refactoring capabilities. By carefully structuring Java projects, I believe that while Java will never have the high degree of programmer productivity of Ruby, Lisp, Smalltalk, etc., it is still a great language to develop in - important because of the obvious benefits of server side Java.

Labels: Java

When I do any database work in Java, I like to support both PostgreSQL and MySQL. The MySQL drivers since 2002 have a GPL license and are not suitable at all (for license reasons) for use in non-GPL projects when you need to distribute your application (but is fine for internal projects). Thus, for non-GPL projects, I use the older LGPL MySQL driver org.gjt.mm.mysql.Driver to stay clean, license-wise.

I do notice that just about all online tutorials that use MySQL with Java use the newer GPL licensed drivers, so I would imagine that many people end up using the GPLed driver in non-GPL projects. Being an open source enthusiast also means respecting license choices of copyright owners.

The old LGPL driver does not support some things like bit values, but since the old driver is open source, I could always tweak the source code if need be. I am a little surprised that the Java community does not fork the old LGPL driver and maintain it.

Labels: Java, open source

I have been investing a fair amount of time learning the Dojo Javascript library but I had an application where I only needed AJAX to handle HTML form input - I wanted a server side function to return HTML to be inserted below the form. Dojo is a huge library so I pulled the prototype.js library out of one of my old Ruby Rails projects (prototype.js is only about 70KB). I put the following in my form JSP page:

<form id="myForm2">
 <input type="text"  id="input_test_form_text" />
 <input type="button" value="Search" onclick="getS()" />
</form>
<div id="searchresults"></div>

<script type="text/javascript" src="prototype.js"></script>
<script>
 function getS() {
  var params = 'query=' + $F('input_test_form_text');
  var x = new Ajax.Updater('searchresults', '/ajax_search.jsp',
                           {method: 'get',parameters: params});
 }
</script>

The follow is a trivial server side JSP ajax_search.jsp that does nothing but returns the original query as an HTML snippet:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

<%
    String req = request.getParameter("query");
    out.println("<p>request for 'query' is:" + req + "</p>");
%>

Labels: AJAX, Java, Javascript, JSP

I have used Nutch for two contracting jobs and Lucene for many jobs. Until today, I have viewed Nutch simply as:

• Quick to configure for target websites to spider and to administer spidering
• Trivial to run search web application
• Web service provider (OpenSearch API)

Today however I started looking more closely at the underlying Hadoop architecture (like the distributed Google file system and their map reduce client library) and at both the available plugins and the plugin architecture. New opinion: Nutch is a platform for building more complex web applications and knowledge management applications.

Labels: Java, search

JRuby 0.9.2 was released a few weeks ago but I just got around to trying it out this morning. My favorite feature is the "JRuby IRB Console". An easy way to experiment with JRuby is to simply to download the console JAR file that conveniently contains the JRuby run time system, has a "tab auto complete", and has readline support. If you have not given JRuby a try yet, download the IRB Console, and follow through the tutorials. Good stuff!

JRuby performance problems:

I love programming in Ruby but find myself working a lot in Common Lisp instead for vastly better runtime performance. JRuby performance is very poor at this time (much slower than the standard Ruby system, which is itself slow), but with support from Sun and some development time, performance and Java platform integration will improve.

Labels: Java, Lisp, Ruby

I have been reading some negative comments on adding web services, embedded database, etc. to the core Java libraries but I think that this is in general a good thing. If you don't like the now "standard" web services libraries, then just use the stack you prefer. The good thing is that it is just about trivial to do two things:

• Export methods from one of your POJO classes as a web service
• Build a client from a WSDL resource (e.g., "wsimport -d generated http://test.com/stock?wsdl")

Java DB (Apache Derby) is a good embedded database and having it in the JDK (but not the JRE) by default makes it easier to deliver small applications to customers and feel more confident that they will have an easy installation experience. I could care less if the JDK download is a few megabytes larger.

Labels: Java

I feel like I have come full circle (almost) in AJAX development: I started out a few years ago adding some simple AJAX enabled forms to a JSP based application. When first starting out, it took hours to get something working. Then a year ago, I discovered how simple it is to use AJAX in Rails: fine, except that Ruby does not have high enough performance for some applications (unless large parts are written in C - Ferret, for example).

I have spent many evenings playing around with various release versions of the Google Web Toolkit (GWT) and it is very compelling, especially if you already are used to developing GUI applications in Java - the only new wrinkle worth mentioning is getting used to handling events asynchronously. The problem with GWT is that it really does tie you to the Java platform. I spend most of my time developing AI applications, but that said, who does not want basic knowledge and competence at building web applications?

I use Common Lisp, Java, and Ruby for development, so for the occasional AJAX tasks that I have, I have settled with the well respected dojo Javascript toolkit because it plays very well with both Lisp and Java JSP based web applications. Dojo is also easy to use with Rails, if you want an alternative to Rail's great AJAX support.

By using Dojo, I basically have to deal with just one learning curve no matter what platform I am developing on. Here is a simple example for a JSP page (assuming that this would be more interesting to most people than a Lisp example):

Add this to your <head> section on a top level JSP page:

    <script type="text/javascript">
     var djConfig = { isDebug: true };
    </script>
    <script type="text/javascript" src="dojo.js"></script>
    <script type="text/javascript">
            dojo.require("dojo.io.*");
            dojo.require("dojo.event.*");
    </script>

Then try putting this somewhere on your JSP page (note: this assumes that you have another JSP page ajax.jsp that gets the form values and returns content to be placed into the DIV element with ID=ajxplydiv. Anthing that ajax.jsp writes using out.print() gets inserted asynchronously into the "ajxplaydiv" DIV element):

    <h3>test AJAX Form:</h3>
    <form id="myForm">
        <input type="text" name="input_test_form_text" />
        <input type="button" name="button1"
               value="Try AJAX form" id="ajaxButton" />
    </form>

    <div id="ajxplaydiv">
       initial context for AJAX play div
    </div>

    <script type="text/javascript">

    var buttonObj = document.getElementById("ajaxButton");
    dojo.event.connect(buttonObj, "onclick",
                       this, "my_onclick_button");

    function my_onclick_button() {
      var ajaxargs = {
        url: "ajax.jsp",
        load: function(type, data, evt){
           dojo.byId('ajxplaydiv').innerHTML = data;
        },
        error: function(type, data, evt){
         alert("Error occurred!");
        },
        mimetype: "text/plain",
        formNode: document.getElementById("myForm")
     };
     dojo.io.bind(ajaxargs);
   }
</script>

The call to dojo.io.bind sends a request containing the form data to the ajax.jsp page, and whenever the results are returned then the Javascript functions "load" or "error" defined in the data block in my_onclick_button() is called. This is just one example of processing form data and adding HTML below the form without refreshing the page - but is a common use case for using AJAX. This example assumes that I have both the dojo "src" directory and dojo.js in my top level web resources directory. The great thing about dojo is that it encapsulates all asynchronous event handling, offers a good supply of visual components (that map to HTML elements) and is simple to use no matter what programming language you are using for a web application.

Labels: AJAX, Java, Javascript, Ruby, search

This is a good thing, to be sure! However, I have to wonder how this might affect Sun's revenue for Java in embedded devices, etc. Sun has a huge investment in Java and as a corporation they really do need to generate revenue from Java.

One thing that I would like to see happen is tight JRE integration with Linux systems: a mechanism for running a shared JVM instance for small Java utilities and porting Apple's contributions for sharing more memory between JVM instances running on the same system.

Labels: Java, open source

I plan on doing a major overhaul to our "knowledge intensive" cooking and recipes web portal including AJAX support and a better artificial intelligence recipe wizard. The portal is written in Java using JSPs and custom tag libraries.

I have actually considered re-writing the whole thing in Ruby Rails, partially for the AJAX support and partially because Rails is easier to develop with. However, after spending a few hours experimenting with the IntelliJ 6 Google Web Toolkit (GWT) plugin and wizard support, a lot of the advantage of Rail's excellent AJAX support is minimized. Both free developers from most Javascript hassles of using AJAX.

The is a short flash demo that is worthwhile watching if you are considering using GWT.

Labels: AJAX, Java

I am about 4 months into a project using a very expensive object persistence mechanism (Franz Lisp AllegroCache) that almost automatically wraps Common Lisp CLOS classes for automatic persistence and B-Tree indexing of as many slots as you want to tag as indexed. As is sometimes is the case, here commercial software tools save time and effort. There is a very interesting open source project for Common Lisp (Elephant) that does something similar by using BerkleyDB or a relational database as the backend - it looks good, but it is not yet an out of the box solution.

For Java work, although I was once a fan of Hibernate, I try to use Prevayler instead: if you add new instance variables to the end of class definitions you can add to your object model without breaking your persistent storage - a neat trick, to be sure.

When it comes to the best programmer productivity using object relational mappers, I personally think that Ruby Rail's ActiveRecord wins hands down - with the slight cost that you design database schema instead of class models.

Labels: Java, Lisp, object mapping, Ruby