Java Collection Performance

This is just a helpful reference when trying to decide which collections to use in Java. I use this for my personal reference but it may help others as well. The links go to the Sun Javadocs. The collections of each type are ordered based on performance (i.e. the highest performance (highest speed) ones are listed first and will be the fastest for most operations)

List - this is an ordered list of objects, insertion order is maintained and retrieval order is in the list order but items can also be random accessed, duplicate items are allowed, generally allow storage of null values (the ones below do), generally fast to iterate and find items by position but slow to do lookups

• ArrayList - Unsychronized, nulls allowed (fastest)
  
• Vector - Synchronized, only slightly slower in tests of sizes under 100000
• Stack - Synchronized, same speed as Vector, LIFO queue
• LinkedList - Unsynchronized, allows two way iteration and modification of items (like a stack or queue)
• CopyOnWriteArrayList - Synchronized, significantly slower in tests of large numbers of items or average list changes, only slightly slower when used with very small numbers (<100)>

Set - this a set of items with no duplicates (no two items can compare as equal), ordering is typically inconsistent over multiple set iterations depending on the implementation but you should assume the order is effectively random unless the set specifies ordered iteration, generally ok to iterate and fast to do lookups

• HashSet - Unsychronized (fastest), slower than HashMap which it is built on, allows nulls
  
• LinkedHashSet - Unsychronized, ordered by insertion, allows nulls
  
• TreeSet - Unsychronized, ordered by the natural ordering of the items or a comparator provided at construction, allows nulls but there are issues with removing them
  
• CopyOnWriteArraySet - Synchronized, significantly slower in tests of large numbers of items or average set changes, only slightly slower when used with very small numbers (<100)>

Map - Stores key/value pairs (maps keys to values) where the keys must be unique, order of iteration over keys, values, or pairs is highly dependent on the implementation of the map, allowed nulls also vary by implementation, generally very fast to lookup keys and slow to lookup values

• IdentityHashMap - Unsychronized (fastest), uses reference equality (==) instead of object equality (equals) to compare keys, actually violates the Map interface guarantee, all iterators are unordered, allows null keys and values
• HashMap - Unsychronized, this is the fastest general purpose map, all iterators are unordered, allows null keys and values
• ConcurrentHashMap - Synchronized, all iterators are unordered, does not allow null keys or values
• Hashtable - Synchronized, all iterators are unordered, does not allow null keys or values
• LinkedHashMap - Unsychronized, all iterators are ordered based on insertion order of the original key (does not change if a key is reinserted), allows null values but null keys are not allowed
  
• TreeMap - Unsychronized, iterators are ordered by the natural or comparator ordering of the keys, allows null keys and values but the comparator needs to understand them
  

Workaround for mvn release:prepare failures

If you are using subversion 1.5.1+ like me you are likely to be frustrated by constant failures while attempting to use the Maven Release Plugin to prepare and perform releases.
There is a simple workaround for this which works like so:

1. Run mvn release:prepare
2. After if fails run svn update
3. Run mvn release:prepare again
4. Success!

The errror here appears to be caused by changes in subversion 1.5.1 so hopefully that will be fixed in the future.

Using find to locate duplicate or missing classes

I found this super useful find command on the webspherehelp blog which I am pasting below:
find . -name '*.jar' -o -name '*.war' -o -name '*.ear' -type f |xargs -i bash -c "jar -tvf {}| tr / . | grep CLASSNAME && echo {}"
Just change the sample Classname to the one you are getitng a conflict with.
It will search though all files in the current directory (or whereever you point the find command) and locate every class file which matches the CLASSNAME text. Very useful.
I needed this to track down a java.lang.LinkageError recently and it worked like a charm.
Here is the original blog posting.

Gmail address matching craziness

This is so crazy it must be blogged about. I got an email which I should have gotten even though it was not actually addressed to me. You are thinking that I am crazy because email does not work that way. Normally I would agree, but check this out:
An email sent to azechoski@gmail.com was delivered to me.
Note that my real address is: azeckoski@gmail.com

Here are the headers to prove it (chopped out some extra bits to protect the sender):

Delivered-To: azeckoski@gmail.com
Received: by 10.151.102.11 with SMTP id e11cs256039ybm;
      Tue, 22 Jul 2008 11:02:35 -0700 (PDT)
Received: by 10.100.205.13 with SMTP id c13mr2655883ang.47.1216749755360;
      Tue, 22 Jul 2008 11:02:35 -0700 (PDT)
Received: from mail2.stellaronecorp.com (mail2.stellarone.com [64.203.182.58])
      by mx.google.com with ESMTP id c40si8810491anc.30.2008.07.22.11.02.34;
      Tue, 22 Jul 2008 11:02:35 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C8EC25.00DD8ED8"
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-OriginalArrivalTime: 22 Jul 2008 18:01:01.0106 (UTC) FILETIME=[E68D5920:01C8EC24]
Subject: Transfer
Date: Tue, 22 Jul 2008 14:01:45 -0400
Message-ID: <7925a85885c9454897dba459745e840d5aa877@west-exch1.stellaronecorp.com>
To: azechoski@gmail.com

Seriously, how cool is that?

Marist Sakai Bootcamp

We just wrapped up the Sakai Marist Bootcamp which ran from June 2nd through the 6th at Marist College in PoughKeepsie, New York, USA. There were 32 participants from universities in Michigan, New York, Maryland, Ohio, Hawaii, Canada (not comprehensive) and commercial groups like IBM, rSmart, Unicon, and Serensoft. This is the first Sakai bootcamp of 2008 and I guess something like the 10th one I have taught overall.
Topics covered included Sakai installation and development environments, Eclipse usage, Sakai code structure, development practices and tips, and various Java development tips. Participants had quite a varied level of knowledge from those who were new to Java and Sakai to those who had been using Java for 10+ years and Sakai for 3+ years. There were participatns from higher ed and K-12. Marist is helping provide Sakai services for K-12 schools around NY state and I had a chance to see how they are using Sakai. I felt like the workshop went really well and I enjoyed my time in Poughkeepsie, NY.
Our hosts at Marist treated us very well and provided lunch and snacks every day and a great location to have the workshop. We went to Shadows (a semi open air restaurant along the river) on Tuesday evening and had a good time with fairly traditional upscale american dining. I was honored to have a chance to meet a dean and the president of the college on the last day.
Cheers to everyone who organized things and gave me a chance to come to NY and hopefully expand the Sakai community.

Flickr photos are posted here: http://www.flickr.com/photos/tags/sakaimaristbootcamp/

Maven2 hibernate DDL generation

I needed a way to get hibernate to generate DDL for me and I ended up using the hibernate maven plugin. It took a lot of trial and error to get it working so hopefully this will save someone some time when they try to do the same thing.

In case you are not familiar, Hibernate is an ORM package for Java that allows you to treat your database like a collection of objects (sort of). Maven2 is a java build system (like ant or make). DDL is data definition language and tends to be unique for every database so if you want a project to work with multiple databases then you have to create DDL for each one. That's where this comes in to play. Normally hibernate will generate DDL and run it for you but this is not always desirable. Especially when dealing with production systems which already have a large database. This will allow you to generate the DDL right in the source of your project and then simply commit the DDL files back to your source repository. If you change your hibernate mapping files then regenerate the DDL and commit the changes.

I created a simple folder with the right pom.xml and the other needed support files to allow a developer to generate DDL by just running mvn install in their ddl folder (the one with these files). You can download that to get started. There is a little bit of setup required which is detailed on my wiki page about generating DDL using hibernate and maven2. Checkout the readme which explains how to use it. I would think it is probably 10 minutes of effort to add this to an existing hibernate project which is using maven 2.

Fun with Maven 2 dependencies

I learned some new Maven 2 tricks this weekend while experimenting with things. In general it can be a real pain when you are developing a piece of framework code which a few projects depend on and you find a minor issue which requires a new release. Typically you have to go around updating lots of POMs. Well, no longer! In maven 2 you can now specify version ranges which can save you a lot of updating when newer versions of packages come out.
Normal maven 2 depedencies look like this:


<dependency>
<groupId>org.sakaiproject.entitybroker</groupId>
<artifactId>entitybroker-api</artifactId>
<version>1.3.3</version>
<scope>provided</scope>
</dependency>


Unfortunately, if a bug fix is released for this which is 1.3.4 then I will not pick up on the new version and would have to explicitly put it in. However, if I want to pick up any minor version updates for a project and I want the minimum version to be 1.3.3 (but less than 1.4.0) I can do this:


<dependency>
<groupId>org.sakaiproject.entitybroker</groupId>
<artifactId>entitybroker-api</artifactId>
<version>[1.3.3,1.4.0)</version>
<scope>provided</scope>
</dependency>

A word of warning though, if the packages you are using do not adhere to standards of versioning you can really get in trouble if a new version comes out with an incompatible interface. Of course, if that happens you simply adjust the version range in the POM.

More info here: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

EntityBroker 1.3.3 released

The new 1.3.3 version of EntityBroker is released. This includes a bunch of new features to make working with Sakai easier but the biggest improvement is full support for RESTful URLs. Now a developer can write an EntityProvider and implement a handful of interfaces and end up with REST access to their entities. This now allows developers to expose data from within Sakai to be read and written via REST calls by other Sakai apps, Sakai helpers, external apps (PHP, Perl, etc.), and client side widgets. This includes support for transformation of entity POJOs to and from JSON and XML automatically. Like everything else in EB, this can be disabled or controlled explicitly if desired. More details on the RESTful entities page.
The other major change in this release is the DeveloperHelperService. This is a shared service that the EntityBroker provides. This service makes it easier to deal with current Sakai data as entity references. Methods include getting current user/location/tool and generating URLs to work with entites and within Sakai. It also provides for some protection against shifting Sakai service APIs as this service API will remain stable and allow access to common things like current user and site without requiring knowledge of the Sakai service structure.
There are few minor improvements in the new version like support for persistent entity properties (without using hibernate) and support for persistent entity tags. There are also improvements in the classloader handling to ensure that the entity system will not hold onto class resources when a classloader reloads (e.g. webapp reload). Thanks to testing by Stephen Marquard this release should be fully backwards compatible with the pervious version.

GenericDao 0.9.5

The 0.9.5 version of GenericDao is now available. This provides the biggest leap in functionality yet with enhancements including support for JDBC and pure SQL (along with Hibernate) and new search methods which use a generalized Search object to make it easy to control restrictions, limits, ordering and bascially everything you would want to put in a search for an object.
For anyone unfamiliar with the package it is mostly a bunch of convenience code to make it a little easier to have ORM like functionality and not have to write the same boring create/update/find/delete methods over and over again. It also provides a simple and extendable interface for working with persistent objects.
I am using the new version to replace the previous hibernate usage in a couple of projects and things seem to work quite well so far. The new version builds on some of the Apache projects like BeanUtils, Google projects like Guice, and the Spring Framework.
I hope to add in support for DDL generation using Apache DDLUtils in the next release.

Download (Maven2):https://source.sakaiproject.org/maven2/org/sakaiproject/generic-dao/
Maven site: https://source.sakaiproject.org/maven2/org/sakaiproject/generic-dao/site/
Javadocs: https://source.sakaiproject.org/maven2/org/sakaiproject/generic-dao/site/apidocs/

On a related note, this release was made using the Maven 2 release plugin which made the process very clean and easy. I recommend it highly.

Subversion Keywords

I finally got around to putting in SVN keywords in some of the files for the Evaluation System project. It took me a little while to figure this out but they don't start working automatically. You have to take the extra step of telling Subversion (via properties) that you want it to actually do the keyword substitution. Luckily the steps are pretty easy once you figure it out.

1) Add some keywords to your files like so:
$Id$
$URL$
2) Run this command from the base directory of your project (this will add all the keywords, just remove the ones you don't want from the string):
svn propset -R svn:keywords "Date Revision Author URL Id" .
3) Commit the code (this will take awhile because it is going to commit a new revision of every file in your project). The keywords will be replaced and look more like this:
$Id: EvalConstants.java 46025 2008-02-27 13:01:48Z aaronz@vt.edu $
$URL: https://source.sakaiproject.org/contrib/evaluation/trunk/$

Disappointingly this will not work for all files going forward so you will have to reapply this for new files or just do the whole set every once in awhile.