April 25th, 2010

by Ivan St. Ivanov

Considering data stores

This article is not from this week, but anyway, it is very interesting and profound, so I cannot help sharing it with you.

What is a data store? Well, this is a repository where you can store data. Author’s idea is to provide a quick overview and benchmark results of a wide range of data stores.

There are certainly several types of data stores – relational databases, object databases, document oriented stores, etc. For each of these types there are different kinds of libraries and even technologies that help the developer work with the data storage. Each of the data stores and the concrete implementations has its strengths and weaknesses. In the beginning the author tries to stress that there is no silver bullet that solves the data storage issues. However, most people (99,99999% according to him) go for the relational database solution and most of those (there is no percentage mentioned) use JPA as the layer between JDBC and the application code. The author calls this no-thought solution SOD – same old data store.

I must admit that I am in the SOD camp – I don’t usually think much when I have to develop a simple application. I go directly to relational DB + JPA. However, at a bigger project where I participated, we had to judge between several persistence representations and technologies, so I had the opportunity to get acquainted with some of them (even a colleague of mine keeps insisting that JCR is the best solution, even though we chose JAXB and XML :-)).

Anyway, the bottom line is that it is good that people like Joe write such reviews so that the next time we’ll take a well-thought decision and not go directly to the SOD.

Groovy closure in pure Java

‘Closures in Java’ is a long discussed topic in the community. And it seems that we are going to have them in JDK 7.

But first, what is a closure? Well, this is can be a very broad and complex area, but the easiest answer is – a function pointer. Hmm, it does not seem quite clear, right? OK, imagine that you can define a block of code and you can pass that as a parameter to normal functions. For example you can define a generic iterate() method over a collection, which receives the algorithm that handles the collection data.

Anyway, we should not wait for JDK 7 to come to start using closures. Most of the dynamically typed languages have them and some of them are built on top of the JVM, which means that they “compile” to Java byte code.

The article described hereby is an example of how you can implement a Groovy method that takes a closure parameter and then create and pass this parameter from withing pure Java code. Short but useful hint! 🙂

The ABC of JDBC, part 1

JDBC was discussed in an earlier article of this blog. So if you liked it, but you are still not very familiar with it, then DZone’s series is just for you.

In the first interview-like installment Daniel Rubio explains the very basic terms of JDBC: how it works, what is a connection and how do you create it, what is a statement, how are connections pooled, what is a DB driver, etc.

5 things you didn’t know about… the Java Collections API, part 1

IBM developerWorks continues Ted Neward’s series “5 things you didn’t know about…”. Now it is time for the Java Collections API. As this is a very vast topic, there will be several parts devoted to it.

In this first part the author starts with the most obvious things – how you can use the API for common stuff: converting an array into a collection, iteration, the new for-each loop and its usage with collections, new and handy collection algorithms and extending a collection.

I personally thought that using the plain old array is better in terms of optimization. Well, not exactly. Think about all the tedious code that you have to write for a single operation with the array. For example a simple dumping to the console requires at least several lines of code. Not to mention extending it with one or several elements. Well, this is handled by the collections API for you. Not only that, but the API designers have overcome all the traps that you can fall into if you decide to work with the array by yourself – concurrency for example.

So, my advice is: use collections as much as possible. It’s easy, it’s fast and your code will be clean and easy to understand and maintain.

JavaScript in Java with Mozilla Rhino

Last but not least, Steven Haines, the editor in chief of the InformIT Java guide created a quick series this week on running JavaScript code inside Java programs using the Rhino library coming from Mozilla.

The usecase presented here is that a certain web application needed same validation to be run on the server, as well as on the client side. The easiest solution would be to develop the validation logic twice – the first time in a language suitable for the browser (e.g. JavaScript) and the second time in Java – our server side language of choice. After a while you can realize that this is not a good idea: developing something twice is one of the worst practices, which we always try to avoid (though I must admit I’m still doing it :-().

So the solution is simple: write the validation code just once and call this same code on both locations. It’s easy to run JavaScript on the client side – all the modern browsers understand it. But how do you do it in Java? Well, Mozilla Rhine does it all and InformIT knows it all.

Don’t forget after reading the first part to go on with the next ones by clicking the Next links at the bottom right of the articles. Thus you will find out how you can combine the result of different functions, how you can build a JavaScript entity using JSON and how you can convert it to a JavaBean with GSON, and finally how you can organize your validation code.

Leave a Reply