Tag Archives: java

What Comes Next

In my previous post I explained why I left JavaEE behind. Now, I’m going to explain my reasoning process to come up with what I’ll learn, teach and use next. The criteria I’m using are:

  • Cloud friendly: the technology should be ready to scale horizontally, without constraints, additional products or exponential use of resources.
  • Learning curve: I should be able to learn and teach fast even if it requires me to change the way I think about programming. I recognize I have lots of new concepts to learn before I realise the advantages of other technologies.
  • Performance: everything I write I want to be faster than any interpreted language. I know that premature optimization is a bad idea, but I need a technology that even when I decide to postpone optimizations it will be fast enough.
  • Community: the community doesn’t need to be big, but it should be active and kind with newcomers. The majority of libraries they produce should be open source.
  • Reusability: I should be able to reuse the libraries I’m used to, or find equivalent ones.
  • Coverage: I should be able to write the same kind of software I’m used to and not be limited if I decide to do more.
  • Documentation: the technology should be well documented, with books, websites, blogs, wikis and teaching materials.
  • Development Stack: the stack should implement MVC for web applications, database migration, database abstraction, SSL, authentication, authorization, REST web services, etc.

The fundamental choice starts with the programming language. It must support functional programming in order to be cloud friendly, but it also has to avoid mutable state to prevent concurrency issues and make it difficult for programmers to write code with side effects. I already use Java, but at this point we have to eliminate it because mutable state is the default behaviour in the language. To avoid it, we have to write a whole bunch of additional code that needs to be tested as everything else. Java requires the use of design patterns to overcome the deficiencies of the language. Static analysis tools, such as SonarQube, are required to keep the code safe, but, unfortunately, they require a significant effort that has nothing to do with the business problem we are solving.

“Most people talk about Java the language, and this may sound odd coming from me, but I could hardly care less. At the core of the Java ecosystem is the JVM.” James Gosling (2011, TheServerSide)

Despite the Java programming language being out of the picture, the Java Virtual Machine (JVM) is still relevant. It’s a portable and mature platform capable of running multiple programming languages in several operating systems with a transparent memory and thread management, with performance peaks compared to C/C++. What Java doesn’t do for us, other programming languages do, running in the same virtual machine and reusing the existing Java ecosystem, which is huge! Therefore, languages that have their own compilers and independent virtual machines are discarded because they hardly will reach the maturity and popularity of the JVM and the Common Language Runtime (CLR). So, at this point we discard Erlang, Harskell, Go, and all other languages that don’t run in the JVM or CLR.

I have mentioned CLR, the .net runtime, but I have no experience with it so far. So, I have to narrow my choices to JVM hosted languages. I couldn’t find any official  or reliable survey about the popularity of JVM languages, but I did find several pools showing that Groovy, Scala, Clojure and JRuby are indeed the top four JVM hosted languages, in no specific order.


Groovy‘s popularity is due to the fact that it looks very much like Java, but without its cumulative historical problems. Therefore, Groovy’s learning curve for Java developers is by far the lowest one compared to Scala and Clojure. Scala comes next with its richer type system and object orientation. We’re able to map our Java knowledge within Scala, but this language is so full of possibilities that it’s the hardest one to master. We have problems to read other people’s code because developers have too much freedom to express themselves. Clojure, on the other hand, is the hardest one to start programming because of its radical differences from Java, but it’s the easiest one to master because of its simplicity. We do a lot more with less code and the code is readable as long as you know functional programming principles. Since JRuby didn’t perform well in the surveys above, I’m discarding it for the moment.

The chart bellow shows job trends in the US, according to indeed.com. It actually reflects the size and influence of the community gravitating those languages. Groovy has been performing well since the beginning, but it is now threatened by Scala, although it isn’t clear yet which one will stand out. The interest for Clojure is constantly and shyly increasing, as functional programming becomes popular and the learning material available helps to reduce the introductory learning curve. In any case, it still has a long way to go.

Groovy, Scala and Clojure have at least the same coverage as Java, with the advantage of writing less to do more. There is absolutely no problem that can be solved only by using Java. Actually, concurrency problems are far more complex to solve with Java, making those alternatives much more interesting.

In order to master those programming languages, I had a look at the volume and quality of the documentation available. This is very hard to measure. For those who like numbers, I have compiled the following table:

Language Appeared Google StackOverflow
Groovy 2003 602K 11468
Scala 2003 1.510K 35207
Clojure 2007 350K 9278

The problem is that this table can be interpreted in many different ways:

  1. These numbers are far from precise. They change everyday because of the nature of the internet.
  2. Looking at the volume, we might conclude that the more entries we get the more documentation we can find, but it can also be a sign of complexity, taking a lot more documentation to explain a thing. Therefore, the fact that Clojure has less entries doesn’t mean it is less documented than Scala or Groove.
  3. Some languages are older than others, accumulating exposure to the community, thus producing more content. But in this case, older content are counted but hardly relevant nowadays.

I can say that the documentation I found was fairly good enough to address all my questions so far.

The last point is the development stack, a set of libraries and frameworks covering most of the needs of a regular enterprise developer. The following table shows a non-exhaustive list:

Feature Groovy Scala Clojure
Build Tool Gradle SBT Leiningen
Persistence Grails Slick HoneySQL
Database Migration Grails Play Framework Joplin
MVC Grails Play Framework
Compojure + Ring
Security Spring Security SecureSocial
Testing Spock Scala Test Expectations
IDE Support IntelliJ
RESTful Web Services Grails Spray
Play Framework

Notice that Grails appears several times in the Groovy column. It’s a web framework offering a good deal of productivity thanks to a Convention-over-Configuration approach. The same happens in the Scala column with several occurrences of Play Framework. While the approach followed by Groovy and Scala offers more productivity and reproducibility, it also reduces the flexibility of the architecture, making it hard to replace an inefficient part by a more efficient one. Clojure is more concerned about the architecture and offers a separate library for every feature. In case a competitor library becomes more efficient than the one we are using, we can easily integrate the new library and gradually replace the inefficient one.

My strategy to use those three technologies from now on is the following:

  • Groovy: when I find a chaotic and inefficient JavaEE application, I will propose to migrate it to Groovy + Grails. It will make the project economically viable again and recover the time wasted with complexity. The team can start writing Groovy code right away in the same project, gradually replacing the Java code and JavaEE dependencies.
  • Scala: the main advantage of the Scala stack is its reactive platform, offering an unprecedented performance boost for concurrent applications. So, when performance is one of the main requirements of the application and the team is smart and organized, I will suggest Scala as the way to go.
  • Clojure: For everything else I will suggest Clojure, which is very productive, simple and has an excellent performance. That’s by far the best programming experience I ever had.

In summary, I still use JavaEE for existing well designed applications, but I will use Groovy to save chaotic JavaEE applications from complete failure. Scala and Clojure will be used for new projects, depending on their characteristics and context of use.

Leaving JavaEE Behind

I’ve been a Java EE supporter for years. In practice, I’ve been using it since the beginning and evangelizing it since 2011 through an open source project called Yougi. This app is currently used to manage the CEJUG community, thus equally useful to manage any kind of communities on-line. But, above all, this project was intended to teach Java EE, giving real world examples of code that people could simply copy and paste in their projects, thanks to its liberal open source license. I believe this project has served its purpose, since it has been forked more than 60 times on GitHub, stared more than 20 times and received contributions from 16 developers. But today, I’m going to tell you a different story. A story that explains why I’m not going any further with Java EE.


Why Am I Not Going Any Further With Java EE?

By September 2013, I was fairly happy with Java EE platform. I was convinced Java EE was in the right track since its complexity was going away (not really… they just hid it with lots of annotations) and many Spring developers were migrating to it. At that time, I had all the arguments to jump into long discussions in favour of Java EE. However, two recent events have diminished my motivation to keep evangelizing it:

  1. Oracle downgraded Glassfish from a product to a basic JavaEE reference implementation: Glassfish was an excellent product but Oracle’s sales team never gave the necessary attention to it and the project became unsustainable. So, by the end of 2013, Oracle decided to stop supporting it. Does it make any difference? Yes, it does. Glassfish gets out of the competitive market, so they don’t solve bugs fast enough and performance isn’t a serious concern anymore. I was using Glassfish at work and at home, for personal projects. So, that means I had to migrate everything to another application server sooner or later.
  2. Migrating from Glassfish to another certified JavaEE server was a nightmare: at first we thought the migration would be easy because we maximize the use of the Java EE specification and minimize dependencies on third-part libraries. However, the migration was so hard that we aren’t even close to finishing it. Libraries and frameworks that follow JavaEE specifications actually behave differently in some aspects that are not sufficiently covered by TCKs (Technology Compatibility Kit). When the team writes software exploring exactly those uncovered behaviours, then the migration becomes a nightmare.

Furthermore, the constant addition of new JSRs (Java Specification Request) to the Java EE specification is actually harming the ecosystem because:

  • it’s slowing down companies and open source communities to catchup with new developments and tests to become Java EE certified. For instance, the Java EE 7 specification was released in June, 2013.  Many app servers are already certified, but we are in February, 2015 and there is no official support provided to those certified servers. So, the TCKs do not guarantee production-ready implementations, which indicates that those tests are superficial.
  • open source communities have to create projects totally from scratch, just to become Java EE compliant. It’s a terrible use of voluntary work. People are wasting their time on constantly reinventing the wheel.
  • some implementations are reused in several app servers and they are rewritten only when their open source licenses are incompatible with other dependencies. It proves that some JSRs have weak motivations to exist, since there is no real competition in some cases.
  • when Java EE implementations are put together, they create a huge complex stack, generating several failure points while trying to make them work together. The more JSRs, the higher the likelihood of bugs and strange behaviours.

Parasitic Problems

With all that complexity comes also the traditional issues that continue indefinitely unsolved:

Constant redeployments: while the redeployment issue is definitely solved in Ruby on Rails, Python, PHP, Play, Clojure, ASP.Net and others, it is still an issue in the JavaEE platform. This problem is there for so long that a business focused on handling that was created. ZeroTurnaround invented JRebel and LiveRevel to minimize redeployments, thus increasing developers productivity. JRebel is a must-have because we constantly lose concentration while the app is redeploying. The waste of time is so heavy without it that JRebel pays itself in a couple of days.

Scalability limitations: for this point I just quote Martijn Verburg in one of his Devoxx talks:

“Traditional JavaEE servers and the technology stack they support don’t scale for the cloud, they don’t scale for the web, not quite yet. Java EE 7 and things like WildFly, supporting micro-kernel and micro-containers is getting a lot better, but if we want to horizontally scale, there is no way we are going to deploy a hundred WebLogics, a hundred Webspheres across our nodes. It’s never going to work, right? There is too much lusts and fluffs involved in those big stacks”.

Java: that’s probably the most verbose language right behind C++. Considering the current offering of programming languages on the JVM, Java is certainly the least productive. It’s actually impossible to earn any money at all without a IDE. All relevant frameworks require you to write getters and setters for classes attributes, otherwise they won’t be able to break classes encapsulation with reflection. Even for simple things you have to write classes and when the amount of classes is not enough, some design patterns will require you write even more classes. At the end of the day, you have more classes than the abstractions of the “real world” you wanted to represent with object orientation. All specifications managed by the JCP most be written in Java, and since JavaEE is a huge state machine, other languages running on the JVM have issues sharing those states.

Source of inspiration outdated: JavaEE evangelists claim that JavaEE is attracting many Spring developers because it finally reached Spring’s innovations with simplicity. However, Spring is already an outdated technology in comparison to reactive frameworks like AKKA and web frameworks like Play. If JavaEE keeps its bad referential, it will soon stagnate, as pointed out by Ron van Kemenade, CEO ING Group, during his Devoxx’s talk:

“The traditional IT vendors, they don’t offer you that. They stick to their old paradigms of whatever they sell you: the enterprise class, they say. Only in my case it always fails.”

It isn’t purely technical, it also comes with legal concerns: JavaEE specs are very conservative, don’t target innovation and have huge legal concerns from companies that contribute to the JSRs. Intellectual property is an issue constantly mentioned in JCP presentations. What they didn’t realize yet is that nobody cares about Java intellectual property since it doesn’t have innovation as a goal and after Microsoft released a multi-platform .Net Framework under Apache license.

Is there a way to save JavaEE from self-destruction?

Unfortunately not. Besides everything I listed above, better alternatives will be so common and mature that applications using JavaEE will enter in maintenance mode in about three or four years time. JavaEE 7 was released on 2013 and there is no official support for it until now, 1 1/2 years later. If JavaEE 8 is released in 2016, then it will be probably available in 2018 only. So, in 2018 developers will be able to do just a little bit of cloud development, while other stacks are mastering the art of scalability. There is no sign so far that JavaEE 8 will take advantage of the new Java functional capabilities. It will be probably postponed to JavaEE 9, finally available in 2021. Of course, they didn’t have time to consider the new Java 9 features, thus real modularity will be available only in 2024, almost ten years from now. This timeline does make sense because if you look back 10 years ago, J2EE was actually impractical and Spring was conquering the world, but this time the competition will be relentless.

By the way, current players will be just fine, because they are already creating strong alternatives to JavaEE (Example: VertX by RedHat and several other Apache projects).

Installing Intellij IDEA on Mac and Ubuntu

It has been a year since I moved my professional and community development projects from Netbeans to IntelliJ IDEA. Netbeans is still a great IDE and I recommend it over any other open source alternative, but the productivity brought by IntelliJ is so great that the time I’ve saved using this IDE already paid off.

I have IntelliJ installed at home and at the office. It’s the same license but the deal is: you can install it in several computers but use one installation at a time. I use Mac and Ubuntu at home and my experience installing IntelliJ in those platforms was the following:

Installing on Mac

I’m not really going into step by step here. IntelliJ is pretty easy to install on Mac, but I had a problem with the JDK and I’m going to focus on that now. IntelliJ uses the JDK distributed by Apple by default, which is a JDK 6 implementation. Well, this is not a big deal, since we can install the most recent JDK and configure our projects in the IDE to use it instead. But, for some unexplained reason, I couldn’t configure the IDE to start the application server in a JDK different from the one used by IntelliJ (JDK 6). In the image below, you can see I’ve configured JDK 8 to run WildFly, which requires JDK 7 or superior, but it didn’t work.


So, I had to change the JDK used by the IDE. For that, I:

  1. closed IntelliJ;
  2. went to the folder where all applications are installed (/Applications) and selected the file “IntelliJ IDEA ##.app”;
  3. accessed the context menu (mouse click with two fingers) and selected “Show Package Contents”;
  4. opened the file “/Contents/Info.plist” and
  5. located the JVMVersion to change its correspondent value to 1.8*.

After this configuration, I could finally make IntelliJ run Wildfly.

Installing on Ubuntu

The installation on Linux is traditionally more complicated. I wonder why people complain about the low number of Linux desktop users. 🙂 The IntelliJ IDEA download page mentions only two steps:

  1. unpack the “ideaIU-XX.Y.Z.tar.gz” file using the command “tar xfz ideaIU-XX.Y.Z.tar.gz” and
  2. run “idea.sh” from the bin subdirectory.

However, this instructions don’t deliver IntelliJ as delivered in other platforms. People don’t go to the installation folder and execute the file idea.sh. They either create a desktop icon or add the bin directory to the path, but these steps are missing. So, in my understanding, the installation is not completed. To launch IntelliJ from anywhere in the command prompt:

Become the root user:

sudo -i

Move the unpacked folder to “/opt/idea”:

mv ideaIC-XX.Y.Z /opt/idea

Edit the file .bashrc:

gedit ~/.bashrc

Add the following line to the end of the file:

export PATH=/opt/idea/bin:$PATH

Log out and log in to the change take effect.

To add the launcher icon on the desktop, there is a soft and a hard way.

The Soft Way

Fortunately, IntelliJ can help you once you run it for the first time. In the welcome window, select “Configure”:


And then select “Create Desktop Entry”.


That’s it!

The Hard Way

As a good Linux user, you may prefer doing it the hard way, as follows:

Create a desktop file:

cd /opt/idea
gedit idea.desktop    

Copy the content bellow to the file:

      [Desktop Entry]
      Name=IntelliJ IDEA 
      Comment=Integrated Development Environment
      Name[en]=IntelliJ IDEA

Install the desktop file:

desktop-file-install idea.desktop

Create a symlink:

cd /usr/local/bin
ln -s /opt/idea/bin/idea.sh /usr/local/bin/idea.sh

Finally, display the idea icon in dash:

cp /opt/idea/bin/idea.png /usr/share/pixmaps/idea.png

At this point, you will finally feel IntelliJ as an application, integrated with the desktop and always ready to be executed.

Look At It Carefully And You Will Find Something To Improve

(This text was originally published at RebelLabs’ Website.)

I propose you an exercise: when you come back to work tomorrow morning, navigate through the source code of your project and try to find opportunities of refactoring. Do it even if your boss didn’t ask for it. Do it because you want some exciting time at work.

Refactoring is the art of changing what is already working fine. But to do refactoring you need an excuse. It could be design improvement, performance issues, security roles, and many other reasons. That’s a risk you take to reduce the technical debit of the application, making it more stable and, somehow, improving your own productivity in the future.

This is not about being nice with the company or with the boss, but being nice with yourself. Why? Because problems tend to accumulate and, at some point, you will lose the control of your code. You will face hard times to deliver results and it will ruin your career.

Well, let’s see this from a brighter perspective instead. You will learn a lot in the process and will soon realize that you are producing better code than you ever did before. The more refactoring you do, the more clever you become until a point where you may reach the level of innovation. But, what does it mean and how do you know you are getting there?

Innovation happens when you find a clear opportunity for improvement on what you are doing and you realize nobody else did it so far (at least you couldn’t find it). That’s not easy, but it usually happens when you do something repeatedly and you find yourself thinking about what would you do to do the same thing faster or cleaner. Let me illustrate this with a true story.

It was about String concatenation in Java: a classical issue stressed by numerous specialists throughout the years and probably ignored nowadays. Before JDK 1.5, despite its readability and simplicity, String concatenation using the operator “+” could produce a very inefficient code. Behind the scene, this operator was replaced by the bytecode equivalent of StringBuffer, which actually implemented the concatenation. The more you used the “+” operator the more instances of String and StringBuffer you would have in memory as well as a good amount of processing time to manage all those objects. Because of that, developers were pushed to use StringBuffer straight away and ignore the “+” operator. Look at the following example:

String title = “Mr.”;
String name = “John”;
String familyName = “Smith”;

String message = “Dear ” + title + ” ” + 
                 name + ” ” + familyName + “,”;

Developers were used to write like that, but they were pushed to write this instead:

StringBuffer sb = new StringBuffer();
sb.append(“Dear “);
sb.append(” “);
sb.append(” “);

You may agree with me that the first example is more readable than the second one. It’s just natural for developers to use the “+” operator when concatenating strings, thus it was unfair to abandon that syntax. Fortunately, compiler guys did something about it, making sure that the JDK 1.5 would optimize concatenations. Instead of using StringBuffer, a thread-safe class, they created a new one called StringBuilder (non thread-safe, thus faster) and they made sure that a single instance of it would handle all concatenations as illustrated in the first example. That’s an important move because they favored elegance instead of technicalities. The first example is automatically transformed at compile time into something like this:

StringBuilder sb = new StringBuilder();
sb.append(“Dear “).append(title).append(” “)
  .append(name).append(” “).append(familyName)

However, concatenations within a non trivial logic still require you to write StringBuilder in your code because the compiler is not that smart yet. For  example:

List<Student> students = studentBean.findStudents();
String intro = “The following students were approved:n”;
String listedNames = “”;
String separator = “”;
for(Student student: students) {
  if(student.approved()) {
    if(!listedNames.isEmpty()) {
      separator = “, “;
    listedNames += separator + student.getName();
String msg = intro + listedNames;

would be more efficient if written like that:

List<Student> students = studentBean.findStudents();
String intro = “The following students were approved:n”;
StringBuilder listedNames = new StringBuilder();
String separator = “”;
for(Student student: students) {
  if(student.approved()) {
    if(!listedNames.length() > 0) {
      separator = “, “;
String msg = intro + listedNames.toString();

Ups! Did you noticed anything strange up there? It might not be obvious at a first look, but see how they check if the variable listedNames is empty before defining the separator. The class String has a nice readable method isEmpty() introduced in JDK 1.6, but StringBuilder still uses that pretty old way of comparison. Why didn’t they do it for StringBuilder and StringBuffer as well?

Discussing the issue at the core-lib-dev mailing list, it turns out there is no apparent reason why they didn’t do that before. Perhaps they simply forgot it 🙂 Thanks to a large refactoring, trying to improve inefficient uses of string concatenation, it was possible to find such inconsistency. I believe they still have time to fix that for Java 8, which is coming out next year. And they would fix that by adding the method isEmpty() in the interface CharSequence to make sure that every other implementation will be equally elegant.

That might be a simple thing, but every single detail matters when Java is under heavy criticism for being such a verbose language. So, go for some refactoring and find opportunities to improve your code as well as the language you use to write it! Let’s move Java forward!

Interviewed by Java Magazine

The March/April issue of Java Magazine is released! You should definitely check this out!

By the way, they actually published an interview we did some time ago, together with Bruno Souza (SouJava, Brazil) and Michael Huttermann (Jug Cologne, Germany). That’s cool! But I’m not a big star as they are, just a Java passionate guy! I do appreciate that! You can read the interview in the picture below or directly in the latest edition.

Many thanks to Java Magazine’s editors for publishing that interview!