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.

complexity

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.

wildfly-configuration

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”:

intellij-configure

And then select “Create Desktop Entry”.

intellij-configure-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 
      Type=Application
      Exec=idea.sh
      Terminal=false
      Icon=idea
      Comment=Integrated Development Environment
      NoDisplay=false
      Categories=Development;IDE;
      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.

Auberge de la Ferme: Wine Choices for Dinner

I never had the opportunity to write about the experience at Auberge de la Ferme. I will do it in another opportunity because now I just want to share our wine choices for dinner. They have an extensive selection of wines in a big cave and every time we go there we spend a lot of time choosing the right one, hoping it is good enough for the occasion.

This time we made a very good choice at a good price. They are:

Montravel

We had a gastronomic dinner with 7 services and most of the dishes demanded a white wine. We choose Montravel, that was one of the waiter‘s suggestions. This is a very good 12% dry and fruity wine 2013.

White wine Montravel
White wine Montravel

Julienas

Some of the dishes demanded a red wine. So, we once again accepted one of the waiter‘s suggestions. The dry, 13% red wine Juliénas 2011.

Red Wine Julienas
Red Wine Julienas

We still are amateurs in the art of wine appreciation. So, I’m saving the choices here for the next time :-) .

Migration from org.cejug.yougi to org.yougi

We have been using the package org.cejug.yougi since the beginning of the project. That’s more than 3 years. Recently, we decided to rename it to org.yougi, removing the package cejug. Why? Because none of our current contributors owns the domain cejug.org anymore. Since we own the domain yougi.org, we felt comfortable to make the change. By the way, CEJUG’s website is now at cejug.net and they still are our main contributors. Thank you very much!

When you update your fork, everything will compile normally, but it won’t be possible to deploy the application due to a Liquibase limitation. That’s the framework we use for database migration. To fix this problem, simply execute the following script directly on your database:

# update databasechangelog set filename = concat('org', substr(filename, 10));

#commit;

Now, the deployment is expected to work normally. Everything gets back to normal. If you forked Yougi after the 4th of July 2014, you don’t have to do anything. Your database will be created already with the fix.

New Technical Philosophy

We used to develop Yougi using NetBeans + Glassfish since the beginning of the project, in 2011. After the issue with Glassfish, we decided to evaluate other application servers. WildFly and TomEE appeared in the radar. After some time analysing both, we decided to migrate to WildFly, which was the only alternative supporting Java EE 7 at the time. Unfortunately, we didn’t reach the same level of productivity as before. We immediately noticed that NetBeans struggled to work seamless with WildFly the same way it works with Glassfish. It’s true that the integration nowadays is getting better, but at that time (beginning of 2014) we were pushed to analyse alternatives for NetBeans.

Screen Shot 2014-05-05 at 23.10.38

The time we have lost migrating from Glassfish to WildFly and from NetBeans to something else was so significant that we decided to change our philosophy. The basis of this change are summarised in two words: freedom and independency. In practical terms, the changes were the following:

  1. IDE independent: we used to promote Yougi almost exclusively through NetBeans. We even suggested people to install it in order to easily contribute to the project. Now, we will also promote Eclipse and IntelliJIDEA. This way, if Oracle decides to stop supporting NetBeans, we will be pretty comfortable with that.
  2. Java EE implementation independent: Yougi was exclusively running on top of Glassfish. Now, we will make sure it runs on top of at least two different application servers: WildFly and TomEE, which are two production-ready open source alternatives for Glassfish. In case one of these servers is considered non production-ready or it doesn’t evolve anymore, we will migrate the entire project to another technology. In summary, we will support the Java EE technology as long as it has two very competitive open source implementations. TomEE doesn’t implement Java EE 7 yet. So, we will start testing Yougi on it as soon as they release a beta version.
  3. We’re still committed to Java: Despite several ups and downs in the last years, Java is still a great technology. It is showing consistent evolution and deals very well with backward compatibility. Even if we are forced to move to another server technology we will think twice before moving from Java. In the meantime, we expect that Oracle keeps increasing community participation, transparency of processes and open source  availability through the JCP (Java Community Process). These are important criteria to keep up our motivation on using the Java language.
  4. … but not exclusively anymore: We recently decided to include Scala and Play Framework in the project in order to  evaluate a new approach for server-side technology. We intend to compare it with Java EE to understand what we are missing in terms of architecture and design. We are going to give more details about this in the post that follows this one.

Screen Shot 2014-05-05 at 23.14.37

This philosophical reorientation has been discussed in CEJUG‘s mailing list in the last 4 months. The debate has been intense and it even produced two relevant publications: an article published on WildFly’s website explaining how to migrate an application from Glassfish to WildFly, and a two pages contribution to a RebelLabs report about migrating from Glassfish to WildFly and TomEE. We are happy that Yougi and CEJUG have helped not only their communities but the entire world with the knowledge we have produced.