« Podcast on SOA and XD. | Main | James McLurkin and robot swarms »

May 17, 2006

ObjectGrid eval copy on web for free download


The evaluation version of the ObjectGrid is available on the web from IBM. You can download a fully functional version of the standalone ObjectGrid. It's an evaluation copy because it stops working after 60 minutes but is otherwise fully functional. 60 minutes should be enough to do performance and functional testing. Once 60 minutes has passed then you just need to restart it to continue testing. It doesn't expire, it just will only run continuously for 60 minutes at a time.

Anyway, please send feedback to the forums or to me ( ).



We'll be updating it to the latest fix level as soon as the level is GAed so usually it's the latest level and if a later one becomes available then simply take the updated evaluation copy from the web site to get the new level.

It's a small download (11MB). Basically, you just need a JDK and an IDE.

May 17, 2006 | Permalink


60 minutes?! Youve got to be kidding me. How the hell do you do a quality evaluation in 60 mins? Is there that little to the product?

Posted by: expireware | May 17, 2006 4:40:56 PM

It runs for 60 minutes, then you stop it and run it again for another 60 minutes, FOR EVER...

Posted by: Billy | May 17, 2006 8:47:08 PM

Thanks for the information! Just downloaded it and trying to write my own sample code.
Good to see that it has sample code and JavaDoc!

I just noticed that there are lots of checked exceptions used in the API...
I do not find it convenient at all. Can you please explain the reason behind it? Is there a way to change it?

Exceptions (in my opinion) to be of Runtime type:

Especially ObjectGridException is irritating...
I have to always wrap it into meaningless try/catch block like this:
res = (MyObj)myMap.get("myKey");
catch (ObjectGridException e)
// Have no idea how to handle it!!!
ObjectGridException is similar to SQLException problem. It is too generic and most of the developers crowd would have no idea how to handle it…as result producing tons of catch blocks that convolute the code.

Any thoughts?

BTW, I’m not trying to start debate here Checked vs. Unchecked exceptions…just want to have as clean API as possible.

Posted by: Ruslan Zenin | May 24, 2006 3:04:38 PM

what do you think about ehcache? We want to give ehcache a try ... what key differences or additional features do we have with objectgrid to ehcache?

Posted by: johannes | May 25, 2006 12:26:12 AM


During our development of this function, we have tried to benefit two customer types, those that like to use Eclipse/Netbeans, etc... and when using those IDEs programmers can benefit from some nice added value for checked exceptions. Checked exceptions help us be more precise in what a user should be planning to handle, e.g. in my opinion we can be better programmers for programmers using that approach.

However, that said, not trying to make an ivory tower here... Obviously, the java map semantics are not using this model as provided in the JDK, and many programmers have grown to prefer this model.

To bridge the two camps, we provide a getJavaMap() on the ObjectMap object that I think will let you use a map as you would prefer. Take a look at the Javadoc for that, as well as com.ibm.websphere.objectgrid.JavaMap and I think you should appreciate you have two paths here, and folks can take the path that complements thier particular programming style.


Posted by: Perry Dykes | May 25, 2006 8:49:16 AM

Thanks Perry for the insight.

OK then I'll use JavaMap(). Still to me API designer has to use Checked exceptions very carefully. It should not be default exception type!

When deciding what type to select (Checked or Unchecked) some of the following questions have to be answered by the API author:
- Does caller of the API know how to handle exception or not;
- Will the caught exception benefit caller of the API or not (e.g. some useful information inside the exception, changes execution workflow etc…)

If the answer is no for the above questions then I think it is wise not to force caller of the API to handle the exception every time...let it fly to the higher level...
Runtime type just gives more flexibility to the caller of the API (catch or not).

Otherwise callers of API will get lots of wonderful code like this:

catch(APIXCheckedException e)
throw new MyRuntimeException("Some unknown error...go figure", e);

However, there are lots of cases in the API development when author wants explicitly force caller to handle thrown exception...then I totally agree Checked types can be employed.

On the other hand, I understand that it is too late to change the API exception types – it is already out…

Billy, what is your take on this issue?

Posted by: Ruslan Zenin | May 25, 2006 1:59:40 PM

I know, it's contentious. Checked exception are nice in IDEs but can add to the code. At the same time, you can always throw the exception on your method and then it's not an issue and give more or less the same behavior, i.e. caller must handle as an unchecked exception. I'm doing this in my test apps now, method throws exceptions if not handled locally and then the method code looks pretty clean.

Thanks for taking a look. Email me with any questions ([email protected]).

Posted by: Billy | May 25, 2006 4:16:16 PM

It's hard to do justice to the feature difference here in a single post, please post this on the forum and I'll figure an appropriate response.


Posted by: Billy | May 25, 2006 4:24:07 PM

Billy, my comment to your reply is here: http://devwebsphere.com/devwebsphere/2006/05/checked_excepti.html#c17801319

And thanks for your e-mail! I will certainly use this opportunity to learn more about ObjectGrid!

Posted by: Ruslan Zenin | May 26, 2006 4:21:19 PM

Post a comment