Tag Archives: open source

TomEE-CLI: An Alternative To Manage TomEE

About a year ago, when I was looking for alternatives to replace our Glassfish servers (why?), I had the chance to evaluate TomEE. Talking to TomEE’s team was indeed a pleasant experience. By far, the best support you can get from a JavaEE player. Just to give you an idea, they replied all questions in less than 24 hours, while we had to wait over a month to get the first feedback from RedHat about JBoss EAP. We had multiple evaluation criteria and, unfortunately, TomEE didn’t go well in the management part. JBoss offered redundant ways to manage the server, including a web API, a command line tool and a web console. Since the infrastructure team put too much weight on the management aspect, I had to agree and formally recommend JBoss EAP. Sometimes, we have to make unpleasant decisions, but that’s business.

As an open source enthusiast, I knew I needed to do something to help TomEE. So, I thought about contributing to the documentation but I had to step back because my daughter had just been born at the time. Looking at my GitHub profile, one can see how much of my free time was filled up with paternity love. The good news is she is growing fast and becoming less demanding, leaving some room for my open source projects.

github-contributions

In January this year, when my brain left hemisphere was in good shape again, I decided to learn Clojure, a functional programming language on the JVM. I’ve got so excited that I started telling my friends about what I would describe as a “mind-blowing experience”. One of them, Daniel Cunha, was particularly excited about that. We were talking all the time about infinity possibilities we have at hands with Clojure. Then he suddenly came out with a project proposal I couldn’t refuse: “Let’s write a client tool for TomEE. I’m trying to write one in Java, but it’s taking too long. Let’s write it in Clojure”. And then I said “Yesss! Of course”. Daniel didn’t realise but he was giving me the chance I was looking for: solving exactly the point where TomEE didn’t do well in our analysis. I’m sure Daniel didn’t expect such enthusiasm coming from a contributor.

On April 13th 2015 we released the first version of TomEE-CLI. We started our endeavour in Mars 9th and we managed to develop 11 functionalities within a month with just 300 lines of code. No doubt Clojure and its ecosystem has made it possible. Can you imagine what we can achieve within a whole year?!

How It Works

We basically developed a Clojure API to manage TomEE instances. This API is so simple that you don’t even need to learn Clojure to use it. Clojure’s syntax to call functions is remarkably obvious. If you aren’t familiar with LISP dialects you will probably ignore the fact that you’re actually coding valid LISPs expressions to manage your server. You may ask your self: “But, it’s an API so I need to write my own Clojure code to use it, right?”. Writing your own code is actually optional because you can use the REPL (Read-Eval-Print Loop) to execute Clojure expressions. In a single line of code you can call any of the functions available. Look how we use the REPL to invoke a function that installs TomEE 1.7.1 Plus in the working directory.

clojure-repl-tomee-cli

The REPL gives a real feeling of an interactive shell. That’s why we didn’t wait too long to release TomEE-CLI. It’s a basic, but valid user interface that people could start using immediately. Features like auto-complete, history and multi-line commands are also provided by the REPL. In the long run, the REPL won’t be the only way to interact with TomEE-CLI. We are planning to add a rich shell interface for experienced hackers, an in-line parameters interface for easy integration with automation tools such as Jenkins, and a web interface for beginners and remote administrators.

You can find installation instructions in the readme file and a complete list of functionalities in the project’s wiki.

You may be surprised I’m devoting time to a JavaEE initiative after leaving it behind. Well, software development is all about people. So, even when a specification sucks, people using it are still good people, thus I’m writing it for them. Besides that, I’m happy to write Clojure code to solve real world problems faced by JavaEE developers in a daily basis.

Daniel and I understand that we may not have many contributors because the actual Clojure source code looks weird for Java developers. That’s what I thought when I first looked at it. But I can tell you that I’m not that smart and I was able to grasp the language in less than a month. Now, I’m delivering new functionalities in a short period of time, preserving the same level of performance and robustness offered by the JVM. When I became a father I realized time is my most precious resource. I simply can’t waste it anymore.

DSC00410

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.

scala-groovy-clojure

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
Lift
Compojure + Ring
Security Spring Security SecureSocial
Silhouette
Buddy
Testing Spock Scala Test Expectations
IDE Support IntelliJ
Eclipse
IntelliJ
Eclipse
IntelliJ
Eclipse
LightTable
Emacs
NightCode
Vim
RESTful Web Services Grails Spray
Play Framework
Liberator

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 CEJUG’s Leadership Team

Today is my last day in CEJUG’s leadership team. A journey that lasted for tireless 8 years or something. I’m not sure about the exact date I became Jug Leader, but I remember very well how it happened. I was attending a CEJUG coordination meeting at Fortes Informática because I was helping them to organize an event. Right after the meeting, Felipe Gaúcho invited me to co-lead the group, which was unexpected but very pleasant. I accepted immediately! Felipe is not among us anymore, but I am eternally grateful to him for this incredible opportunity.

I’m not leaving because I’m tired or bored. I’m leaving because CEJUG needs renovation. It needs to change its philosophy, its soul. I’m the oldest one in the leadership team, thus I’m a dinosaur in terms of community management. My mind still believes in some practices that don’t work anymore and the community is not growing as it could grow. Fresh and valuable ideas usually come from new people with a vision to help others to develop their technical capabilities. I’m sure there are a lot of people like that out there and I wish they get my place and move on faster.

There is a CEJUG’s rule that promotes ex-leaders to become advisers for the leadership team. It is a sort of recognition for the great services provided to the group. But I’m not accepting even that. To give advices to a future leader is like bringing back the old way of thinking. That’s what I’m trying to avoid. Advisers are not so active anyway. I don’t remember the last time I received an advice from them. Actually, it ended up becoming a definitive leave for them too. Eventually, my departure will motivate other members of the leadership team to take the same initiative, if they have the same feeling I’m describing in this post, of course.

Sometime ago, a friend of mine was excited about CEJUG’s community and he asked me what he has to do to become a JUG Leader. I told him that it’s not so difficult, but it requires patience and a lot of work. That’s because CEJUG is a meritocracy, where you are recognised according to your contribution to the community. The recognition is basically promoting you to the leadership team, then you have more power and resources to make things happen. It takes some time because we wanna make sure that you won’t give up easily and you will just continue working as hard as before.

The problem is that there is no glamour in the role of Jug Leader. New leaders probably realised that it’s more a labor of love, donation and dedication than a professional achievement. Some people love that, like I do, but most people don’t. Perhaps new leaders won’t find motivation for the merit in this meritocracy model. The excitement may last for a few months and then, even the free time will be occupied with other priorities.

I have been proud of my role as a Jug Leader, not because of what I did for the community, now and in the past, but because of what I feel for them and what I was willing to lose for them. I will keep this feeling in my heart. You may ask me why I’m leaving since I’m still in love. This is like a relationship that doesn’t work. When your love is not reciprocal the best thing you can do is set your love free.

If you want to be the next CEJUG Leader, be aware of the need for passion, donation and dedication, with or without professional achievement. In addition to that, read a very interesting post on John Yeary’s blog about the definition of a Jug Leader.

By the way, I will continue as a humble CEJUG member, trying to help people there with their technical questions. Meanwhile, I’m working on a new open source project! I’m going to launch it here soon and maybe it will end up in a new, large and successful community! 😉

Integrating Jira with Netbeans

One of the advantages of hosting your open source project at Java.net is the availability of Jira to track your issues. Jira is one of the most popular issue tracking system available on the market, which drives tool developers to support it. This is the case of Netbeans, my working IDE, and also the case of Eclipse.

I recently configured my Netbeans to access Jug Manangement‘s issues. If you want to do the same, or with another project hosted on Java.net or even connect to the Jira available on your company’s Intranet, then the following instructions may help you.

The first step is to install Jira plugin on Netbeans. In the menu, select Tools and then Plugins. Go to the tab Available Plugins and select JIRA. Follow the installation procedure and restart the IDE at the end. The figure below shows the plugin already installed. You may check as well if JIRA is in your list of Installed plugins to make sure everything went well.

In the view Services, where we connect to databases, webservers and others, we also find a new kind of service called Issue Trackers. By clicking with the right button on this service, you are about to create a connection to a issue tracker. A dialog like the following figure appears. Give any name to your connection, since this is not a predefined value. In case of Java.net, use the URL https://java.net/jira and the credentials you use to authenticate in the portal. Click on Validate to make sure that you input the values correctly and the connection with the server is working. Click on Ok to finish.

Now, you are connected but not ready to work yet. The next step is to find the issues. For that, click with the right button on the issue tracker that you just created and select the option Find Issues. It opens a new tab in the editor area where you are able to build your query as you usually do using Jira on a web browser. When you build the best query for your needs you can save it to constantly work with that. In the following figure I built a query that shows me all open issues of the project jug-management.

You can do something similar to your project and control your issues directly from the IDE. One of the main benefits of this approach is that, by restricting the use of the browser, we reduce the probability of losing the focus on the work due to other entertainment activities on the web such as news, social networks, chatting and so on.

Choosing Between Vaadin and JSF

With the recent release of Primefaces 3.0, JSF finally reaches an unprecedent level of maturity and utility that puts it face to face with other popular Rich Internet Applications (RIA) options, such as Google Web Toolkit (GWT), ExtJS, Vaadin, Flex and others. This open source project also proved to be very active and in a constant growing path.

I have been working with JSF + Primefaces since October 2010, when I started developing the project JUG Management, a web application conceived to manage user groups or communities focused on a certain domain of knowledge, whose members are constantly sharing information and attending social and educational events. JSF is a standard Java framework for building user interfaces for web applications with well-established development patterns and built upon the experience of many preexisting Java Web development frameworks. It is component-based and server-side user interface rendering, sending to clients (web browsers) pre-processed web based content such as HTML, JavaScript and CSS. My experience on this technology is openly available on java.net.

Meanwhile, I had the opportunity to create a Proof of Concept (PoC) to compare JSF and Vaadin in order to help developers and architects to decide between one of them. Vaadin is a web application framework for RIA that offers robust server-side architecture, in contrast to other Javascript libraries and browser plugin-based solutions. The business logic runs on the server while a richer user interface, based on Google Web Toolkit (GWT), is fully rendered by the web browser, ensuring a fluent user experience.

The result of the PoC was surprisingly interesting 🙂 It ended up proposing both technologies instead of eliminating one of them. I found out, exploring available books, articles, blogs and websites, that despite being able to implement all sorts of web applications, each technology has special characteristics, optimized to certain kinds of those applications. In practical terms, if we find out that JSF is better for a certain kind of application, that’s because it would take more time and code to do the same with Vaadin. The inverse logic is also true. In order to understand that, we have to visit two fundamental concepts that have direct impact on web applications:

  • Context of Use considers the user who will operate the application, the environment where the user is inserted, and the device the user is interacting with.
  • Information Architecture considers the user of the application again, the business domain in which he or she works on and the content managed in that domain.

Notice in the figure bellow that the user is always the center of attention in both concepts. That’s because we are evaluating two frameworks that have direct impact on the way users interact with web applications.

Visiting the concepts above we have:

Environment
Some applications are available for internal purpose only, such as the ones available on the intranet, other applications are used by external users, such as the company website.

Users of internal applications are more homogeneous and in limited number, which means that the UI can be a bit more complex to allow faster user interactions. That explains the fight Microsoft Office vs. Google Docs. The last one is not yet fully acceptable in the office environment because it has less functionalities than Microsoft Office. The latter is, on the other hand, more complex and more expensive. However, a limited number of users to a larger number of features makes acceptable to have some additional costs with training sessions to profit from the productivity features.

A company website targets heterogeneous users in unlimited environments. It is not possible to train all this people, thus simpler user interfaces with short and self-explanatory interactions are desirable.

Considering the environment, we would recommend Vaadin for homogeneous users in limited environments and JSF for heterogeneous users in unlimited environments.

Device
Different devices demand multiple sets of UI components, designed to look great from small to large screens. Fortunately, both frameworks have components to support the full range of screen sizes from regular desktops to mobile devices. The problem is that different devices bring different connectivity capabilities and the application should be ready to deal with short band-width and reduced transfer rates. In this case, Vaadin seems to be more suitable for multiple devices, as long as the variety of devices is not so extensive, because the user interface is rendered locally, using JavaScript, and it has a richer Ajax support to optimize the exchange of application data with the server.

Business Domain
In principle, good quality UI frameworks such as JSF and Vaadin can implement any business domain. The problem is how experienced the team is with the technology or how small is the learning curve to master it. Business is about timing and the technology that offers the best productivity will certainly win. If your team has previous experience with Swing then Vaadin is the natural choice. If the previous experience was more web-oriented, manipulating HTML, CSS ans Scripts, then JSF is recommended.

Content
Content is a very relevant criterion for choosing between Vaadin and JSF. In case the application needs to deal with volumous content of any type, such as long textual descriptions, videos, presentations, animations, graphics, charts and so on, then JSF is the recommended over Vaadin because JSF uses a web content rendering strategy to profit from all content-types supported by web browsers without the need for additional plugins or tags. The support for multiple content is only available on Vaadin through the use of plugins, which must be individually assessed before adoption.

User
Last, but not least, we have the user, who is the most important criterion when choosing a UI framework. We would emphasize two aspects:

  1. The user population: the largest is the target population the highest are the concerns about application compatibility. It must deal with several versions and types of browsers, operating systems, computers with different memory capacity and monitor resolution. All these without failures or security issues. For larger populations, the most appropriate technology is the most compatible one in a cross-platform environment, which is the case of JSF, since it uses a balanced combination of HTML, JavaScript and CSS, while Vaadin relies only on JavaScript and CSS. But shorter populations would have better profit with Vaadin because cross-browser compatibility is and will remain being a very hard work to be done by Vaadin’s development team behind the scene.
  2. User’s tasks: If the application is intensively operated by users then it is expected that it has more user’s tasks implemented. On the other hand, if the application is rarely used or has short intervals of intensive use, then there is a lower concentration of user’s tasks. According to the PoC, Vaadin is the technology that provides the best support on delivering user tasks with richer user interaction because of its fast visual response. JSF is less optimized on which concerns the user interaction.

In conclusion, instead of discarding one of these frameworks consider both on the shelf of the company’s architectural choices, but visit the criteria above to make sure that you are using the right technology to implement the expected solution. A simple way to apply those criteria would be to assign weights to each criterion, according to the project’s characteristics; set which technology is appropriate for each criterion; and sum the weights for each technology. The highest weight elects the technology to be used in the project.