Coding in Java: Keep it Simple

17 July 2013
By Denis Tsyplakov, Delivery Manager

The recent technological leap we can observe doesn’t look extraordinary to us. It began about 50 years ago, and each decade the speed increases. We have become used to complex technologies, compound gears, and multi-step solutions. Nevertheless, one of the drivers of progress is the simplification of existing processes, because it leads to one of the major business benefits – costs reduction.

Developers, especially those who have a direct impact on a production process, streamline existing operational mechanisms. Even when working with data that requires multilevel operations, as in my example – in case of programming in Java. Learning how to simplify your work is a skill possessed by advanced specialists. I’d like to provide just one example from my own experience with some conclusions I reached afterwards.

Struggling With Java Complexity

Java people and clients find the benefits of the language obvious – from the beginning Java had a nice database interface, probably the best one at the time and still the best one even now. However, even simple operations required wordy, heavy requests and complicated sequences of actions, not too complicated, but inconvenient for sure.

Working with an ORM system (a programming technique for converting data between incompatible type systems in object-oriented programming languages – Wikipedia) for Java – a framework called Hibernate, I thought that I’d found the easiest, best documented, and if I may say so, ideologically correct, way for me at that time (and it seems that not only for me) for interaction with databases. Unfortunately, tiresome work with codes makes ORM and Hibernate party poopers.

Why I don’t like ORM anymore?

  • A long learning curve
    Hibernate documentation is not that big and seems like it is easy reading. But based on my experience interviewing more than 50 Java developers, I can confidently say that only 3 of these Hibernate developers were able to answer some advanced questions about this framework.
  • HQL – an additional language to learn
    It’s not enough to know SQL to use Hibernate, you have to learn HQL, which is rather simple, but its semantic differs from SQL’s.
  • Misc
    There are also some miscellaneous issues such as the large amount of libraries to be included, some overheads at the start, more load on the CPU, etc.
  • It’s easy to shoot yourself in the leg – the existing human factor
    It’s easy to forget something, to have a lack of knowledge, and so on. Frankly speaking, completely innocent things can suddenly cause strange side effects, as it often happens.
  • This list is endless

But is there something regular developers can use instead?

Right now Spring JDBC seems to be a good replacement for ORM, being a light, simple, and stateless JDBC abstraction, enabling us to write database requests and obtain results with a single line of code. Operations with system process require fewer commands to be written and processed. Everything is very compact, functional, and with practically zero overhead.

By choosing this method of interacting with databases I’ve not only decreased the time required, but significantly reduced the development costs (time equals money).

Simple and Affordable Things

My experience shows me that the time you spend searching for simple development solutions; new tools, frameworks, technologies, will totally pay off in the future. As a developer or consumer, while doing a risk calculation or costs forecast, don’t forget to make an analysis of all available options that can solve your problem. Companies that provide different industries, from Financial Services and Media to Healthcare and Travel, time-to-market development with the help of highly skilled software engineers, like DataArt does, have the ability to choose the correct options of up-to-date technologies and services.

Nevertheless, while trying to be a pursuit in terms of costs and time reduction, remember what proverb says: “The cheap things proven to be expensive at the end”.

Tags: ,


Add Comment

Name Mail Website Comment

  • Frisian

    23 July, 2013 09:32 am
    How about keeping your use of Hibernate simple? Hibernate's native query capabilities are perfectly fine except one little glitch (http://jdevelopment.nl/hibernates-pure-native-scalar-queries-supported/). No HQL needed. Using the stateless session divests oneself of all the state management. In a last step manage relationships and collections yourself, like you would with JDBC and the learning curve almost becomes a flatline. As much as I like Spring JDBC for simple data models, it isn't overhead free: You code the mapping of the data going into the database (insert, update, delete) in a different place than the mapping for the data coming from the database (select), and it's your job to keep these mappings consistent. With Hibernate there is only one mapping for both directions.