Finally Automating Tests

Yougi has been around since January 2011. That’s more than three years of continuous development. The project has accumulated a total of 13 direct contributors throughout these years, 53 forks, 580 commits, producing approximately 18k lines of Java code. Unfortunately, none of those lines are covered by unit and integration tests. That’s a shame.

It’s time to change that. Starting today, we’re going to continuously write unit and integration tests to guarantee the high quality of this project and teach the community how to do it in a proper and effective way.


We will start writing unit tests to cover classes that don’t depend on the container to run. All we will need for this is JUnit 4. We’ve identified more than 60 opportunities for this kind of test and we already created all test classes and test methods for each one of these opportunities. Check this out at After a while, when we accumulate a good number of unit tests, we will start writing integration tests with Arquillian. We have two reasons to postpone it a little bit:

  1. we have to make available a continuous integration server (i.e. Jenkins) for the project in order to run integration tests every time a commit is pushed to the repository.
  2. we are still learning how to make the best use of Arquillian, which is not so obvious to configure and use. We will share our knowledge as we learn it, but if you already master it, then your contribution is very welcome.

We believe writing tests is probably the most important contribution to an open source project. So, we would like to ask you to help on this effort by implementing some of these tests. It will make a huge difference on your CV, since Yougi is already a mature project. All you have to do it:

  1. Fork the project on GitHub:
  2. Build and deploy it locally.
  3. Choose one or more tests to do and discuss them with the community in the issue #197. It will help us to organize who is doing what and share the knowledge we have about the business logic.
  4. According to the feedback you received from the community, start writing your tests and submit a pull request when you are done.
  5. We will analyse your pull request and suggest changes if necessary. If not, we will simply accept your pull request, closing the flow of contribution.

If you already want to contribute with integration tests, please read the discussion going on at issue #66. It’s not urgent, but every contribution is welcome.

If you have questions about the unit tests, you can comment below or directly on the issue #197.

Book Review: Enterprise JavaBeans 3.1

Enterprise JavaBeans 3.1We decided to review the book Enterprise JavaBeans 3.1 because it’s one of the technologies we actually use to develop Yougi. We genuinely love this technology and this book is very valuable as a reference to make the best use of EJBs. If you have a web profile or a full stack app server, then EJBs are the way to go for your business components.

Of course EJBs are not the solution for every problem. We wouldn’t recommend it to develop content-based websites, games, or desktop applications (although it is possible). EJBs were designed for server-side and highly transaction business-oriented applications. It’s unfair to criticize it out of this context. The technology was designed taking into account the consensus of many industrial parties, coordinated by the Java Community Process (JCP). For every new release they come out with a formal specification that is used by the industry to provide competitive implementations with exactly the same functionalities.

The book is very comprehensive, making it work like a reference book. It even contains a whole part dedicated to Java Persistence API (JPA), which we think it’s too much because there are so many details in JPA that it would deserve a dedicated book. That’s why we noticed this part of the book a bit superficial. Apart from that, the book is full of working code, the authors try hard to be vendor-independent and, of course, it’s a quality assured O’Reilly book.


The contrast between the old and the new way of learning

The EJB 3.2 specification went final in May, 2013, but EJB 3.1 is still the latest production-ready release provided by all major players in the enterprise market. Many people agree that EJB 3.0 was a game changing for the JavaEE platform since the disastrous EJB 2.x architecture. We disagree. I think the real game changing came in EJB 3.1, when the technology became more mature and competitive in comparison to Spring. Even when you pick EJB 3.2, you see there is no fundamental change to the model. Just addition of new features. Having said that, you won’t lose any relevant knowledge by deciding to learn EJB 3.1 now instead of waiting so long for a brand new EJB book coming out. The book Enterprise JavaBeans, published by O’Reilly, is the only one I know with the richest set of details about this technology.

What would you use EJBs for? Basically, when you want to simplify the implementation of the business logic directly related to the management of relational data. The convention is that the container will manage the transactions for you and all the complexity behind inserting, deleting, updating and querying the database. The code becomes very clean and easy to read. In addition, any business method can be exposed as a web service with just a few annotations.

On the other hand, if you don’t use a relational database or use a NoSQL database, probably EJBs are too much for your needs. You can still use them to simplify the implementation of singletons, schedule the execution of methods asynchronously, and consume data from queues, but the real added value is its robustness to keep your data consistent without boilerplate code.

Fork Yougi’s project on GitHub to see how we make use of EJBs.

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!

java 8

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

How a JUG is Born and Stays Active Over the Years

We recently attended EMEA IOUC Summit 2013 in Ghent, Belgium, last spring (EMEA IOUC stands for International Oracle User Group Community from Europe, Middle East and Africa). This meeting was very important because that’s an opportunity that user group leaders have to share what really works and what actually doesn’t work when managing their community.

EMEA IOUC Summit 2013

After acquiring Sun Microsystems, Oracle included Java™ User Groups (JUGs) in IOUC and many JUGs within EMEA were invited to attend the summit. According to some veterans, the gathering at the beginning was like water and oil. Now, they’re much more in line, but there is still a rich diversity in terms of organisation and culture. That’s a real cultural mix.

JUGs are used to be independent and lean. They are supported not only by Oracle, but also by several players, such as RedHat, IBM, Google and others. They are less attached to products and more attached to solutions, which is inherited from the spirit of Java™: “Write once, run anywhere”. Oracle does respect that, continuing as the main JUG supporter out there and avoiding interfering in JUG’s organisation. The coordination of community initiatives is always done with JUG leaders, who contribute with ideas and actions through their respective user groups.

Recently, Oracle and community leaders realised that the process of creating new JUGs was outdated. Ironically, the process was heavy and difficult to manage, not fitting in Jug’s philosophy. Perhaps, it explains why it didn’t really worked. Bruno Souza, an active Java evangelist, was involved since the beginning and gave further details about that:

“ was always structured to be a ‘code’ site, and because of that, it has the concept of project approval and the incubator. Project approval was the step where an admin of a community would consider relating a project to their community (for example, the Desktop community would probably not accept a server side, JEE project). A JUG’s project approval was very loose. If someone said their project was a JUG, we simply took their word for it. The project then would be accepted into the ‘incubator’, that was a staging area, were the project could start, and be clearly labeled as ‘incubating’. To graduate from the incubator, we had a series of steps, that have evolved over time to include the JUGs Map and other basic requirements.”

He concluded saying:

“Of course, as time went by, some of this got lost, some of the approval process started to be done by support staff and not by the JUG leaders, many JUGs never completed the incubator steps (we have around 40 JUGs on the incubator right now), and many JUGs don’t even know about any of that.”

Then Oracle started a discussion with some community leaders (Bruno Souza, John Yeary, Nichole Scott, Tonya Moore, Sonya Barry and Frank Nikola) about what is working and what is not working. They came out with the following process to create and maintain JUGs:

  1. A prospective JUG leader joins and requests a project with the proposed JUG name.
  2. At creation, the project owner receives an automated email asking him(er) to contact the community manager at to request that the new JUG project be made public.
  3. The JUG leader can choose between, their own hosting provider, a social network or any other online service to host JUG’s online content. In case it is hosted elsewhere, the leader just have to add the external link in its project profile. Actually, the only reason has to create an actual project is to prevent name collisions and keep the database consistent. The project itself can be entirely empty.
  4. asks for a KML file to add the location of the JUG in the map, in case it hasn’t been supplied yet.
  5.’s team adds the JUG to the map and make the JUG’s project public, moving it directly to the main JUG community.


Paired with this, will start an annual review of JUGs. The process works this way:

  1. Once a year, people listed as “admin” in JUGs’ projects receive an email asking if they’re still active and if needs to update any information on the site. The reply can be as simple as “yes, we’re still active, no changes”.
  2. If doesn’t receive a positive reply within 30 days, they will follow up with a bit of a research to see if they can find the JUG in question. Perhaps the leadership has changed or a URL has been updated.
  3. tries a second contact using any new information they have. If necessary, they translate the message to the local language.
  4. If doesn’t receive a response to the second inquiry within 30 days, then they send the final notice.
  5. At 90 days without a reply, moves the JUG project to an archive/inactive state and removes the marker from the map.
  6. A quick note is sent to the leaders’ list, letting them know which JUG has been retired.


Any retired JUG can be reactivated at any time, by going though the first process described above.

The intention, as pointed out by Mattias Karlsson, JFokus organiser, is to be “generous and don’t set boundaries if anyone wants to start a JUG.”. Sonya Barry, director of community Infrastructure at Oracle, believes the goal is “to grow the community, and make it easier to join and more inclusive”.

These processes started running in March 2013, too soon to figure out what is coming out of them. They invite further discussions a year from now to see how effective they are. But it is already good news to have established and transparent procedures. Congratulations for the team involved!