Category Archives: Community

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).

Case Study: CEJUG on the AdoptaJSR and AdoptOpenJDK Programmes

CEJUG, one of the most active JUGs in Brazil, decided to join the programmes AdoptaJSR and AdoptOpenJDK in January 2013, led by Helio Frota and Hildeberto Mendonça. These programmes are jointly managed by the London Java Community, UK (LJC) and SouJava, Brazil. An initiative from the community for the community to transform passive java users into active java contributors. The programmes target java specifications, namely JSRs (Java Standard Request), and the OpenJDK, an open source implementation of the Java Development Kit.

Moved by a great excitement, CEJUG also joined the Java Community Process (JCP) by February 2013. They believed that if they manage to give concrete contributions then it would help them to push those into future releases. If it happens at least once, then it would be a great achievement for the local community.

In addition to the OpenJDK, CEJUG also decided to adopt the following JSRs:

JUG leaders, together with active members, have communicated the programme to the community in an event that happened in March, 2013. They picked up those JSRs and asked people to look around, test the API and give some feedback about what they were looking at. They clearly stated that every single feedback matters, even simple things like readability, clarity, completeness, and so on.

Unfortunately, apart from the community leaders, very little effort was spent by members on the programmes. Action was missing indeed. CEJUG was not putting into practice the expertise shared by other JUG leaders. In any case, leaders and active members heroically gave contributions almost exclusively to the AdoptOpenJDK programme:

  1. Event launching the programmes AdoptaJSR and AdoptOpenJSR
  2. Event TecTel IFCE Tauá
  3. Reduced the required memory to build the OpenJDK 8
  4. Issue created: JavaDoc problems when building with OpenJDK 8
  5. Logo that can be used by projects that run on Java 8
  6. Discussion about the inclusion of the method isEmpty in the class StringBuilder

Some months later, they realised, during informal talks to some active members, the word “Adopt” was too heavy for them. It might be a cultural thing, but they understood that as “Taking Care”. It sounded like they would need to allocate quite a lot of time to make something relevant to finally give a feedback. They felt somehow constrained by the responsibility of “taking care” of something so globally relevant.

Time passes. Glassfish 4 was released. All JSRs they have adopted went final. After that, they felt some activity gaps from the programme. Meanwhile, folks quietly started playing around with JSRs, not in the context of the programme, but because of their jobs, PoCs, training, university courses, etc. They were keeping that for themselves until a day in October 2013 when a member discussed an issue in the mailing list. That was the tipping point that moved others to report their own issues as well. The issues were in a much smaller granularity than an usual adoption case we’re used to see in the programmes. Smaller in terms of impact, but when put together they could actually be considered relevant.

This time, the contributions sounded more concrete, visible and with positive feedback from spec leaders and implementation leaders. That’s what they did in an one month period:

  1. Issue created: Request parameters lost after realm form authentication to access a protected page
  2. Reviewed and Improved the Text of the JSR 354 Spec
  3. Issue created: Sequence of adding a JsonArrayBuilder into a JsonObjectBuilder interferes in the final result
  4. Issue created: @NotNull check fails in String attribute when using group validation
  5. No alternative for @ManagedProperty to get Request Parameters
  6. Partnership with Bulgarian JUG to resume collaboration on the AdoptOpenJDK programme (on going)

In summary, it was practical and realistic for the CEJUG community to give smaller contributions to several JSRs without the heavy “adopt” label. At the same time, they don’t want to pass the message that the word “Adopt” should be replaced. Actually, the names of the programmes sound good and they are well disseminated. However, CEJUG does suggest that “adopt” should be kept in an umbrella level, and “contribute” could be a term used to define actions taken by JUGs on JSRs. Therefore, instead of saying “We’re adopting the following JSRs” we could say “We’re contributing to the following JSRs”.

CEJUG strongly believes that by transforming community members from passive consumers to active contributors, they are concretely moving Java Forward!

Glassfish Is Now A JavaEE Toy

If you are using Glassfish in production, as we are, you probably know that Oracle won’t provide any commercial support for Glassfish 4 and beyond. They will keep supporting Glassfish 3.x for a short period of time, but they will push those customers to migrate to WebLogic from now on.

If you are an open source supporter, as we are, you’re probably very upset. We know this Oracle’s move helps to diminish the sustainability of the open source business model. It shows that the replacement of an open source product by a proprietary one is worth doing it. Well, sometimes, this is just incompetence of the sales team and/or product manager to read signs from the community and from the market to achieve better results. Maybe, it didn’t happened to Oracle because they simply don’t understand the open source business at all. We can easily list some open source products with a ruge use base: MySQL (Alternative: MariaDB), OpenOffice (Alternative: LibreOffice), Hudson (Alternative: Jenkins) and Glassfish (Alternatives: TomEE/JBoss/Wildfly). Oracle had them all, Oracle lost them all.

Oracle keep insisting that Glassfish is not dead. The thing is: who decides whether Glassfish is dead or not is the community around it, not Oracle. If the community feels that the software is not reliable enough to be used in a real world environment then they won’t support it anymore. When there is no commercial interest in an open source product it means there is no sense of urgency to solve its bugs anymore. Some of those bugs may stay active for a long time. Since nobody can permanently live with bugs then the natural move is to abandone that technology and migrate to another one. At least, that’s what we are thinking about right now.

If we were lazy or afraid of changes, we would certainly move to WebLogic, but we are not. Our wish for freedom through open source is more important, even if it means a good deal of adaptations to another application server. We actually see it as a learning opportunity. We want to see the code. We want to see where the bug is and show it to the technical support. If we are clever enough, we could simply fix it and send the fix back to the community. None of this can be done with WebLogic.

We were happy Glassfish users and contributors. It gave us the feeling of being there first. We’re still using it to run instances of Yougi out there. We contribute to many other open source projects that use Glassfish as a JavaEE server. We use it in our daily jobs. We have reported several bugs, tested Glassfish 4 like crazy to use it one day. We were excited to heavily promote Glassfish in our community thanks to its fast move towards the latest specification. Now, we don’t find any motivation to keep doing what we were used to do. This is bad for the entire JavaEE community because they were used to contribute to a product that people would actually use after a while. Now, they have to find some other place to put their valuable code. It happens just now that the programme AdoptaJSR is attracting so many contributors.

Now we have to find an alternative and it is not that hard. We believe the natural move from Glassfish is towards TomEE/JBoss/Wildfly. No, we don’t care whether WebLogic can understand Glassfish deployment descriptors or they share some libraries or the basic support is cheaper. These are not good criteria because they are short term ones. When doing such a move we have to look beyond, long term, years ahead. We also have to take into account the risk of disappointment, frustrations and slowness towards the latest specification. We have to measure how close we are from the engineers who actually change the code base.

By the way, that’s the biggest advantage of the JavaEE specification. When we get upset with a supplier we can simply move to another one and keep 99% of the code unchanged. JCP rocks  in that sense!!! That’s something you can’t do with Spring or .Net. If Pivotal (that already took the unstable role of Spring Source) or Microsoft fail or you get upset with them, you have no alternative, but rewrite your entire application to survive in the long run. We hope they never fail but shit happens sometimes :-/

Speaking at Brussels JUG: User Experience for Business Process Applications

I’m glad to inform that I will speak at the next Brussels JUG‘s event about user experience thinking and design for business process applications. The event will take place at Hogeschool-Universiteit Brussel, Building Hermes, on Thursday, 30th of May, at 6:30 pm. Visit Brussels JUG website for more information:

You won’t find a lot of information about this subject on this blog, but I have been doing research about it in parallel since 2006, in collaboration with Kênia Sousa, who would be happy to share the stage, but she had to decline due to family duties. You may find more information on the page Publications of this blog.

If you were assigned to design and implement a business process based application, You may find this session interesting. User interface design is the most time consuming task in a software development process. It is highly subjective and under heavy criticism by end-users. This presentation will help you better deal with this problem, exploring strategies to represent business processes in a way that end-users can easily understand what they see based on their business knowledge. We will discuss about a different approach for Business-IT traceability based on UX, an architecture and a methodology to support constant process changes, navigation approaches and the right widgets for the right actions.

See you there!