Java Without Heartburn

3 April 2015 | By INSART Team

How to Avail Oneself Best at Some of the World’s Best Programming Technologies

By Vasiliy Soloshchuk, Eduard Fastovsky, Sergei Matikaynen,
Vitaliy Gonchar, Vyacheslav Z. Tibilashvili



It’s not going to come as much of a revelation that absolutely any technology, no matter how advanced and sophisticated it is, works better for some purposes, and proves to be less efficient for others.

In this sense, Java is no exception, and although it does suffice for solving virtually any tasks, nuanced understanding of how it should best be used in specific situations and technology combinations can be often be very helpful. And this is exactly what we’ll dwell on in this article based on our extensive experience with one of the world’s most popular programming technologies.

The article may be of interest to those CIOs and CTOs of hi-tech companies, who are faced with the need to implement a project in Java, but have no background in this technology.

What Is Java?

Java is a development technology that is widely used to develop a broad array of applications that include SaaS, enterprise software, cloud solutions, and more. The technology provides the full set of means for building a classic information system that consists of a database to store the information, the business logic layer to manipulate the data, and the presentation layer (a user interface) to communicate with a user and capture their behavior.

The following table contains the various development means provided by Java technology, and listed by purpose.

UI: Client side

Angular.js / Backbone.js + RESTapi

UI: Server side


Business Logic

Spring Framework, Java Platform Enterprise Edition


JDBC, Spring JDBC, MyBatis, Hibernate, JPA


We’ll try to compare the technology options that are intended to serve the same purpose.

Finding a Common Language with Your DB

Working with databases is one of the areas where several Java-based technological approaches exist to choose from. In our opinion, there are three major technology options, each of which has its own advantages, but may also be burdened with certain limitations:

  1. Using plain? JDBC.
  2. Using JDBC-based lightweight frameworks that include Spring JDBC, MyBatis, and more.
  3. Using JPA/Hibernate.

It’s worth mentioning up front that if it’s a legacy database you are working with, the throes of choice are something you can get rid of and forget, because using pure JDBC is the only feasible option. This technology should also be opted for if high processing power and the ability to perform complicated DB operations are among your top priorities: JDBC will definitely ensure the former, and provide support of intricate SQL queries to enable the latter.

JDBC would also be an excellent choice if you feel that using your DB’s internal capabilities, such as stored procedures, the DB’s own languages, expressions, and so forth, is necessary, or would just be beneficial to your project.

Just another of JDBC’s advantages is that data modification queries don’t get cached after execution by default, and you can create your custom cache code by yourself.

However, prior to making a decision in favor of JDBC’s, undoubtedly tangible advantages, consider the following peculiarities of this technology that given the circumstances, may be considered limitations:

  • Unlike with JPA/Hibernate, you, as a developer, have to be familiar with DBs, and have at least some command of SQL. Is that the case with you?
  • The resulting software will be highly DB-specific. In plain English, if you need to migrate the program to another DB, this may be rather problematic, if not impossible. The problematic areas may include primary key generation, stored routines syntax, and data types.
  • At the end of the day, you are due to be saddled with a hefty amount of excessive code.
  • It will be more difficult to update the DM structure, as the same modifications will have to be made to several parts of the code.
  • Data retrieved from the database will have to be parsed manually.
  • DB connections and related resources will have to be managed by you manually.
  • Any exception will need to be analyzedand handeled by you in a custom manner.

    If, at first glance, the pros of using JDBC do not outweigh the cons, the second option you have consists of using one of the JDBC-based frameworks.

    Incidentally, one good solution would be using Spring JDBC that is capable levelling the bulk of the existing limitations. In particular, Spring JDBC solves the problem of resource management, facilitates significantly working with exceptions and transactions, and handles processing of query results.

    Another good framework that can complement JDBC well is MyBatis. Although it does slow things down a bit, it will spare you a lot of routine hassle: getting connected to the DB, making a query, parsing the result, and inserting the data into a corresponding table will be done automatically. All you need to do is create an entity whose fields correspond to the fields of a DB table, and then, based on this entity, create a so called mapper that constitutes a simple interface. The methods of the mapper are associated with annotations (@Insert, @Select, and so forth) that contain JDBC queries.

    Just like Spring JDBC and MyBatis, another ORM-based technology that can situationally afford several advantages is a Java Persistence API implementation, or Hibernate. This is the oldest technology of its kind, which means that most of the potential issues in existence have been addressed, and resolved by its developers.

    Being an industry standard and part of Java EE JPA ensures uniformity of implementations across all application servers. Also, Hibernate/JPA is easier to maintain, which can be quite an important factor for larger-scale enterprise systems. But Hibernate/JPA’s most notable feature is the ability to eliminate the need for SQL queries by providing means (Data Access Objects) for automatic code generation based on the database schema. This speeds up the development process.

    The technology also makes it possible to quickly switch between different databases. The built-in caching capability allows quick access to frequently addressed data, which can make the procedure significantly faster than with JDBC.

    Unlike JDBC, where database connections have to be opened and closed manually, Hibernate/JPA provides an automatic Database Connection Management capability. The DB Transaction API is also supported out-of-the-box.

    However, whenever a higher processing power is the top priority, JDBC is, normally, more preferable: it outperforms Hibernate/JPA due to the provided ability to compose SQL queries more precisely. To achieve the same performance with Hibernate, query profiling may be required in case the level of the developer’s expertise is not sufficient to fully understand the details of the ORM concept.

    The Frontend Dilemma: Let’s Look It in the Face

    Selecting a front-end technology is in no way easier than making a good choice of a server-side technology. The main factors that must be taken into account include the system’s processing power and functionality, required maintenance, and development speed.

    As far as frontend development is concerned, Java Server Faces (JSF) and Java Server Pages (JSP) are the two great technologies that should also be carefully compared to determine which of them is a better fit in your particular case.

    While JSP is a technology specifically designed for creating web pages, JSF is a Java-based framework, the primary purpose of which is to facilitate the development integration of web-based interfaces. It is best suited for presentation-oriented applications. JSF provides an impressive array of out-of the-box functionality and ensures a very high speed of development for complex applications with intricate functionality. Unlike JSP, JSF allows creating web-based applications using only model objects (JavaBeans) and views (JSP/HTML).

    Regrettably, the technology is not all that easy to maintain, its customization and optimization abilities are lower than those of JSP. JSF’s processing power is also nothing to boast about compared with that of its rival technologies.

    JSP is more suitable for service-oriented applications. It allows you to create complex applications with a high processing power. The major drawback is such applications are, normally, code-intensive, and, consequently, difficult to maintain (a large amount of code is required for controlling, validating, data-gathering, conversion, and other purposes). However, with your MVC pattern implemented based on JSP, you can count on several tangible benefits:


    • Your application will be a lot more flexible due to a much greater divide between the control functionality, presentation functionality, and data behavior. Changes made in one of the areas won’t have as much of aneffect on the two other areas.
    • You will be able to use the varying skills of your team members more efficiently due to the ability to assign corresponding tasks more clearly.
    • Due to the improved quality of the system structure, your code will be easier to maintain and extend.


    Talking of front-end development, in our opinion, an excellent option to choose is Angular.js + REST.

    AngularJS’s key features are client side MVC architecture, Directives, and Templates. The framework includes attributes, or directives that are used within HTML pages, and help build models (javascript). Similar functionality is provided by such frameworks, as BackBoneJS, EmberJS, and KnockoutJS.

    It is easy to integrate AngularJS with other libraries, such as, for example, JQuery.


    AngularJS based Front End and Back End API Interaction

    AngularJS makes it possible to use MVC in designing the front-end. The directives and filters the framework provides, or allows creating, give the developer more flexibility and render the code more clear.

    In addition, AngularJS provides several more functional capabilities that can be considered as the framework’s advantages, including 2-way data binding, HTML Partials, easy integration with other libraries/frameworks, and unit-testing support. AngularJS also provides a relatively simple mechanism for the front end / back end interaction using XMLHttpRequest, or JSONP.

    However, just like in the case of any other technology, these advantages come with what can, sometimes, be considered limitations.

    AngularJS’s newer versions do not support legacy versions of browsers, such as, for instance, IE 8. If you aren’t starting your project from scratch, AngularJS will not make your work with the existing code any easier. All the way around, –you will have to completely redesign the existing pages.

    Moreover, if your developers have no previous experience with AngularJS, they must have the will, time, and opportunity to read up quite a bit on the technology to start working with it. This makes the framework more suitable for larger projects.

    It is worth mentioning, that Java has a rich set of tools for building an MVC of its own, and it is easy to use template engines with Java as well. If you are dealing with a fully Java stack-based application, it makes sense to go with only Java-based technologies. On the other side, if you need to separate the front-end from the back-end, and you intend to build a large-scale multi-module application with modules written in .Net, Java, or Ruby, it may be expedient to go for AngularJSbased front-end with REST API integration. This will give you more flexibility, and independence of the back-end implementation. When combined with REST, the AngularJS framework provides powerful functionality, ensures a high processing power, and doesn’t create any significant customization or maintenance problems.

    Spring Framework vs Java EE: It All Depends On Your Project’s Specifics

    We’ve been using both the Spring Framework and Java EE extensively enough, and appreciate both technologies . One can say, that Spring and Java EE provide virtually the same functionality.

    FeatureSpringJava EE
    Size of the application archive (war, ear, etc.)Big (the archive contains all the required libraries, as Spring does not depend on the server).Small (as all the required libraries are found on the Java EE webserver/application server
    SecuritySpring securityJava EE Security
    Use of the IoC (Inversion of Control) patternSpring IoCContexts and Dependency Injection (CDI)
    Web FrameworkSpring MVC, Spring WebFlowJSP, JSF
    WebSocketSpring WebSocket APIThe Java API for WebSocket (WebSocket)
    DatabasesSpring JDBC, Spring DataJDBC, The Java Persistence API (JPA)
    BatchSpring BatchThe Batch Applications for the Java Platform API
    Web ServicesSpring Web ServicesThe Java API for XML Web Services (JAX-WS)
    REST Web ServicesSpring MVCThe Java API for RESTful Web Services(JAX-RS)
    MobileSpring Mobile, Spring for Android
    Social mediaSpring social


    Angular_JS_Frontend_api_Backend select JSR-000342 Java EE 7 Specification for Evaluation JavaEE_Platform_Spec.pdf

    While Java EE is undoubtedly a powerful and hugely popular development technology that can be the optimal choice in the right context, it is our impression that the Spring Framework is, in some instances, faster to react to the various important novelties (for example, the framework supports Android and social media).

    Please note, that to be able to use some of the Java EE technologies, the developer needs to have either a container (a web container , an EJB-container, etc.), or, even, an entire application server, – this isn’t required for the Spring Framework, – Spring libraries alone will be enough. The container or application server for Java EE must be able to fully support the corresponding Java EE specifications, and may have its own capabilities that will have to be used. The latter affects the cross-platform ability of Java EE-based projects: other containers /application servers may not include this functionality, or this functionality may be implemented differently, which then necessitates modifications to the project. Conversely, all you need to be able to work with with Spring, is the framework’s own, and possibly, Java EE libraries.

    Also, new versions of the Spring Framework are released more frequently. Java EE’s main versions appear, on average, twice a year ( However, updates for the new versions are released quite frequently. For example, Spring Framework 4.0 was released in December, 2013. Currently, a stable version (4.1.2) is already available. Java EE’s current version (7) was released in the spring of 2013, the previous one – in December, 2009. The technology’s next version is planned to be released only in the third quarter of 2016.

    It is worth mentioning, that with Java EE, you will have at your disposal a large selection of official specifications, developed by experts as part of the Java Community Process ( Additionally, you will be able to choose from the multiple different implementations the technology provides, while with Spring only one single technology implementation can be used.

    Both the Spring Framework, and Java EE have their own security means. With Java EE, the provided security means is dependent on the Java EE container. Conversely, Spring Security (the security module of the Spring Framework) is very flexible, and it can be used in any runtime environment.

    Notably, in some instances it would be expedient to use both the technologies for the same project. For example, in order to reduce the amount of code, the Spring framework can be used to facilitate the development of non-corporate and non-industrial Java SE applications, where using Java EE alone would be excessive.


    In the present article, we’ve offered you a brief review of the several great technologies we are familiar with. Our personal opinions about them may differ from those of other development professionals. The latter may happen for two reasons: firstly, the extent to which one is familiar with a range of different technologies always varies. And, secondly and most importantly, any one of the above cool technologies can be preferential given the right context, and we have personally made sure about that more than once. In this sense, it is only you who can make any of the above technology choices preferable to the rest by carefully comparing their specifics with those of your project.


    The views and opinions expressed in this article do not constitute an endorsement of, or advice to use/purchase, or not to use/purchase any software technology product. These views and opinions are provided solely for information purposes, and interested readers should also be reliant on other competent opinions. The opinions expressed may differ from those of other experts, who have used the technology products mentioned in the article in different business circumstances, for different purposes, and/for the resolution of different technical tasks, and whose technology expertise and related experience in the said technologies may differ from those of the experts who have contributed to this article.