In My Toolbox: CDI

One thing that Java developers may not complain about their ecosystem is choice. There is so much choice in Java, at all levels, that it may seem sometimes daunting. What to choose when getting the job done?

Take Dependency Injection^*), for example. Besides well established names like J2EE servers or Spring, we have lightweight, standalone solutions such as Google Guice or PicoContainer.

The disadvantages of Spring, Guice or PicoContainer are … well … their lack standardization. If you choose to work with any of them then you’re bound to their semantics (although Spring starts to move towards supporting the standard semantics of dependency injection from Java Enterprise) which is the open-source variant of vendor lock-in.

So, for standard-compliant dependency injection we’re pretty much stuck with an application server … or not? Actually not, because – thanks to the wonderful standardisation process of Java – we do have server-independent dependency injection. Java CDI is the name and it was formalised over various JSRs (I know of 299, 330, 346 and 365).

To sweeten the deal, there is a good-quality implementation: JBoss Weld. Weld can be (and it is) used in application servers, web servers or servlet containers or (and this is what I am talking about) it can be fired up straight away from a plain, simple, Java executable.

How It Works

I’ll show portions of the code of a small web server application which I wrote today. It embeds Jetty for web infrastructure, it makes use of Apache Wicket as a web framework and it encapsulates command line parsing (i.e. Apache CLI) in a class aptly named as CmdLine:

In My Toolbox: NetBeans

My favourite Java IDE, NetBeans, is not disappointing (again): it has the simplest and most effective integration with Gradle. To understand this, I’ll tell how the other IDEs fare with Gradle - according to my recent experience.

Eclipse

I could not make the Gradle plugin for Eclipse to work reliably. It may be that the project I was working on had strange features, I don’t know. But I expected to point Eclipse to the build.gradle file and the IDE to do the rest. To be sure, it did load the file but I could see no project content.

The solution that other Eclipse users employed? Using the eclipse plugin of Gradle to generate an Eclipse project. Fine, as long as you don’t have custom build steps. If you do, then you have to tweak mess up with the cleanEclipse and eclipse tasks to handle the peculiarities.

In other words, to develop a plugin. Hurray, back to Maven in Gradle clothing!

In addition, Eclipse was slow.

IntelliJ IDEA Community Edition

For a while, I could not setup the main runtime class for modules imported from a Gradle super-project (containing about 60 sub-projects). The reason: IntelliJ IDEA 16.1 changed behaviour (compared to version 15) and now it creates separate modules for the main and test directories of each sub-project. Thus I ended up with 201 modules instead of about 60 – with no possibility to run my apps because they could not find the main class. Obviously, this was a special case. I trust that in majority of situations the Gradle support for IntelliJ does work. But it didn’t work for me.

How do I know that was the cause? Switching to version 15 eliminated this strange effect and I could run my app. What remains of keeping with the latest version?

In addition, it seems that IntelliJ doesn’t use the Gradle files except at the beginning – when it generates an IDEA project behind the scenes and then it continues on its own. Also, IntelliJ was slow. 

NetBeans

In its good tradition, the NetBeans Gradle plugin just worked – even though it’s provided by the community. No fuss, no huss. I loaded the build.gradle file and it loaded the project with no problems – and it was fast, too. Very much like the most excellent NetBeans support for Maven.

As a result, I stopped struggling and I just switched to NetBeans to work on my Gradle projects. I still keep Eclipse and IntelliJ around, but the main tool remains NetBeans.

The Day

These details relate to the fact that the NetBeans Day 2016 is just around the corner. I am looking forward to take part to this nice conference and see what’s new in the NetBeans landscape since the 2015 edition.

Aux bons entendeurs, salut!

In My Toolbox: Ansible

I’ve recently put my hands on a powerful tool: Ansible, the secret weapon that can greatly simplify a developer’s life.

What is Ansible?

It is a tool for Linux automation. It is heralded as a serious contender for Puppet or Chef but its capabilities go well beyond server configuration and/or DevOps. Its special characteristics are:

• easy to use and understand: just .ini files, YAML and Python
• well integrated with Linux: works over SSH, no daemons necessary
• follows a common-sense philosophy: idempotency, aiming towards a prescribed goal
• versatility: nice programmability and great combinatorial power

The last two qualities make Ansible a tool as valuable for a development team as it is for an admin/DevOps team.

To Build or Not To Build …

It is well known how hard is to design a good build system. I would dare say that, for the Java world, producing a good configuration system is even harder. But there is hope: a good build system combined with the power of Ansible makes life easy again.

Configuration … what?

Distributed systems in general, and Java distributed systems in particular, use configurations. Lots of them. It is a necessity, if we want to keep our distributed systems flexible.

But configurations are costly to manage. There are lots of duplications: tens of services may have configuration elements like my_secret_port=35400 repeated over and over again. Should a change occur, it becomes a burden to propagate on more than a handful of services or servers.

Gradle + Ansible

Here is where the combined power of two great platforms, Gradle and Ansible, comes to the rescue:

1. The product does not (primarily) store information in config files; it stores them within a dedicated set of text files listing the assets of the system
2. The build system, by the power of Gradle, generates the config files in the right place. Duplication (virtually) eliminated!
3. The build system, by the power of Gradle, generates the playbooks (recipes) that Ansible will use. Repetitive manual work (virtually) eliminated!
4. The deployment system, by the power of Ansible, deploys the modules by running the playbooks generated by Gradle onto the nodes that come from the asset files mentioned above

Easy, safe and sound.

Templates, maybe

The generation of the Ansible playbooks and Java config files may come directly via Gradle (some plug-in development in order) or, much easier and safer, via a template-ing system like Apache FreeMarker. But, about that, I will write in a future article.

Gradle is really groovy

I am about to finish Building and Testing with Gradle. Quite an impressive piece of software, the Groovy-based Gradle. I like how it is (somewhat) procedural (like Ant), somewhat declarative (like Maven), easy to alter (like MSBuild) and based on a clear concept of interdependent units of work (like make).

Once you understand a few notions such as project, task and dependency, that’s pretty much it. Everything else can be explored with ease. For example, one can write a try.gradle inspecting little script:

task disect << {
  def t = tasks[System.properties['what']]
  t.properties.sort{it.key}.each {
    println sprintf('%1$-23s ==> %2s', "${it.key}", "${it.value.toString()}")
  }
}

and then run gradle -b try.gradle disect -Dwhat=tasks to obtain the properties of task ‘tasks’ (-Dwhat controls which task to inspect):

The Green, Green Grass of Home

The things fall into place.

After 3.5 years of software development exclusively on Microsoft platforms (mainly .NET but also Excel; with some Oracle back-end, that’s true), I am coming “home”: I am joining a trading company where the main development platform is Java. Looking forward to it.

Java, home?

Why do I call Java as “home” given that I was born and raised in Microsoft¹⁾ and I’ve worked much more on Microsoft technologies than on Java? Perhaps because I feel that Java (as an ecosystem) is … well … more … homely (in a way).

EnumJ Demo 1.0.0 is public

As I mentioned here, my intent was to write a small Java application that shows how to use EnumJ enumerators. A first draft of this application is ready, published on GitHub and its releases closely follow those of EnumJ.

Meanwhile, I started working on EnumJ 1.1: enumerators over primitive Java types.

EnumJ 1.0.0 in Maven Central

EnumJ 1.0.0 is officially in Maven Central. I am preparing a small demo application that will show, very succintly, how enumerators and enumerables can be used for fun and profit.

The next step is EnumJ 1.1.0 which will contain the same powerful constructs (enumerators and enumerables) but for primitive types.

Back to JIRA

“The way to get started is to quit talking and begin doing” (Walt Disney)

After a brief attempt to use Freedcamp, I decided to stick with JIRA – and to pay $10/month for a good product.

Why not Freedcamp

Freedcamp is a good product, it really is. Good looking, polished, its creators really know their Ajax craft. The problem with Freedcamp was that it lacks two important features:

• the ability to assign estimations to tasks; there aren’t even time-based estimations
• the ability to cut the workload into batches of equal duration; be they sprints, iterations or whatever – the name matters less than the fact that we must work in smaller chunks in order to get things done

If we are to add the miriad of other choices and features that JIRA (a very mature product) brings, it turns out that free may be … more expensive that $10/month.

Why Freedcamp

There are situations when Freedcamp may be a better choice than JIRA. One such situation is to stay on top of many tasks that come irregularly and cannot be grouped into a longer-term project. Unexpected or irregular errants (changing the passport, replacing credit cards, buying new shoes to replace the ones broken in school) may be better supported by a tool like Freedcamp, with its GTD-like flavour.

But more importantly …

… is to actually do it (as Disney put it so well). Unfortunately no tool, no matter how suitable or sophisticated might be, will do the work for us.

Wouldn’t that be nice?

Happy New Year

Firstly, new year, new blog. I decided to open up a blog on Finance. You can check its first post here. It will still be an IT blog, but with focus on Finance matters.

Secondly, I am in the process of switching to Open Live Writer simply because the old blog editor from Microsoft doesn’t work with Blogger.com any more. Too bad, the new editor is not as stable as the old one.

Thirdly, and most importantly, Happy New Year!