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:

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.

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.

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:

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.

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.

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.

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

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 https://github.com/htmfilho/yougi/tree/master/src/test. 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:

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.

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:

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

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:

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:

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!