alt
October 3rd, 2012

by Ivan St. Ivanov

Continuous delivery

My first session of the day was John Ferguson Smart’s on Continuous delivery. Being a fan of the agile software engineering (ASE) practices, this topic was particularly interesting for me as the title and the abstract of the talk promised that we’ll see some best practices in the area. To be honest I’m not a blind follower of everything that ASE prescribes. In my opinion applying every practice on all projects is unnecessary. However, the continuous integration to me is vital, not less than having unit and acceptance tests for example. The most important reason for that is that, as the speaker mentioned, it gives you regular feedback on how your project is going.

The most important continuous delivery principles are the following:

  • Every build, i.e. every commit, is a potential release
  • You shouldn’t have some kind of QA department that runs 6 week test cycles before you go to production
  • Automate as much as possible
  • Trust your tests, be confident that you are ready to go productive

The focus of the talk was on how you can use Maven and Jenkins to ensure a successful continuous delivery process.  However John stated that Maven’s snapshot builds contradict a little bit to the first principle of the process. What he proposed in this case is that you should use the version plugin after a successful build, give your snapshot a real version (for example 1.0.123, 1.0.124, etc.), run the acceptance tests and then publish.

Some other best practices mentioned by the speaker were:

  • Never use the Maven release plugin (to be honest, I don’t remember why)
  • Use Failsafe plugin for running tests instead of Surefire. Have separate configurations for running quick junit and slower integration tests
  • Don’t do mvn deploy on every module of a multi module projects. Because if one of the projects’ build fails, the others will not be run and your central repository will have different versions that might not work together. First do mvn install and do the deploy only after everything passes successfully
  • Deploy to production should be a manual operation. It might be triggered by your continuous integration server, but it should definitely ask you for approval before doing the real deploy

Finally John showed everything in action. He presented the Jenkins configurations of a project, where he basically explained the different steps of the build pipeline.

The presentation is already available on slideshare. Be sure to check it out if you are doing continuous integration and delivery.

JVM JIT for dummies

The next session that I attended was Charles Oliver Nutter’s JVM JIT for dummies. JIT stands for Just-in-time compiler and it is the module, part of the JVM, which is responsible for optimizing the executed code while the program is running. I got a little bit interested in this topic after reading these two excellent posts on JavaWorld (and the third one is still to come). The speaker, also known as the JRuby guy, is doing compiler optimizations for quite a few time now in his effort for better performance of that language. It was a really informative session and the author explained the matter in a way that even a dummy like me could understand most of it.

So, when you run javac, the source code is compiled into byte code. Which is then interpreted by the virtual machine. But if the story would end here, the Java programs would not perform as well as expected. That’s where the JIT compiler kicks in. It performs various optimizations on code that is executed very often (10 thousand times is the default threshold). These pieces of code are called hot spots (hence the name of the virtual machine – HotSpot). These optimizations may include:

  • Compilation of interpreted byte code to native code
  • Inlining method bodies in calling sites to avoid executing a separate method. In that direction Charles showed the assembly code for a method that returns the sum of its two parameters. It contained one instruction for calculating the sum and 7-8 more for doing the method call and return the result – what an overhead
  • Loop unrolling – whenever the number of iterations of a loop is clear, just execute their body for as many times to avoid moving the instruction pointer
  • Lock coarsening and eliding – moving and removing synchronized blocks when appropriate
  • Escape analysis

Then the speaker continued explaining the different types of HotSpot virtual machines:

  • Client virtual machine: it is optimized for fast starts. Doesn’t do too many optimizations besides a few inlines
  • Server virtual machine: does aggressive inlines based on profiling during the application “warm up”
  • Tiered virtual machine: takes the best of both worlds. It starts quickly like the client VM, but after some time starts profiling and optimizations

Then Charles showed the different HotSpot compiler options (those that start with -XX) which help you to fine tune it as well as to monitor things like native compilation and method inlining. He explained in details what the different entries in the monitoring meant. Finally he advised us to always use small methods as large code cannot be inlined, and also not to use long method call chains.

Forge in action

Next up was a talk very anticipated by me. JBoss Forge is the open source project to which I occasionally contribute some small changes and bug fixes. The speakers were the project lead Lincoln Baxter III and one of the most active contributors outside JBoss: Paul Bakker. There was one more reason why I was interested in this particular session – I am going to talk about Forge at Java2Days conference in Sofia in less than a month.

So, what is actually Forge? It’s a tool that helps you bootstrap your application (be it desktop, web app or a simple library). That’s what Maven also does with its archetypes, but the latter stops there. While Forge continues to help you integrate all the technologies that you need whenever you need them: persistence, RESTful web services, integration tests, anything that you might imagine. It also relieves you of memorizing, googling and copy-and-pasting all the different code snippets that you might need in order for you application to run: pom.xml entries, persistence.xml, etc. The first time you do it, it might look interesting. However with every new application this repetitive boilerplate would drive every developer mad. And the best thing about it is that Forge creates the bare minimum of artifacts so that your project is not polluted with stuff that you might not need later (Maven archetypes again?).

After the short introduction, Lincoln and Paul proceeded to the demo, which took pretty much the whole talk. Basically Paul played the part of a curious developer that wanted to develop a task tracker web application and Lincoln added feature by feature using Forge. I’m not sure whether I ever mentioned that it is a plugin based command line tool, which integrates great with the Eclipse IDE in its own view. So Lincoln created a new maven project for the application that they planned to develop. No, it was not done with the Eclipse wizard, but using the according tool command. Then he continued setting up and adding new functionalities. And Forge did whatever was requested reporting the incremental changes that it made. It was smart enough to keep in sync with the changes done in the IDE. Lincoln also installed plugins that were not part of the tool core – these tool extensions were on Github, Forge downloaded the code, built it and integrated it in a breeze.

Even though Forge has a massive number of existing plugins, sometimes you may want to do something that nobody has developed functionality for. Doing it by yourself is not a big problem: writing a plugin is quite an easy job. There’s a pretty comprehensive guide on plugin development at the tool’s website. And the greatest thing is that anyone can contribute their plugin: push it to github, register it in the repository and boom! everybody is able to use your functionality. This is what I call social coding!

If you are interested and are going to Java2Days or Devoxx, make sure to visit the respective talks there. And if you wish to contribute, this is the mailing list, so join in!

Some BOFs

At the end of the day I decided to visit a couple of Birds-Of-a-Feather sessions. You remember, these are talks on a very specific topic, which are usually attended by the most interested (and usually advanced) developers. The topics that I went to watch were about things that I plan to bring home and follow up after the conference.

The first BOF was about JEDI – an educational initiative by the University of Philippines and Sun (now Oracle). They have created (and most importantly, keep up-to-date) materials for nearly 20 university courses. Starting from Java 101 and covering such topics as web development, web services, mobile development, security, etc. The courses are free (licensed under the Creative Commons license) and besides in the Philippines, they are taught also in Brazil, Vietnam and Indonesia. As an assistant teacher in our University of National and World Economy, I got very interested in the project and will contact our professors and see whether it is possible at all to use these courses (the documents are written in English).

The second BOF was on the Adopt OpenJDK project. As I wrote in my first JavaOne blog, I got very interested in this topic and plan to propose it to our JUG when I get back home and even start doing bugathons. While I was drinking a beer in the Buzz House (IBM sponsored street spot, where JavaOne attendees have beer and coffee for free) during one of the afternoon breaks, I met Ben Evans, one of the London Java Community leaders. I asked him to give me some more details and possibly contacts for any question. And he told me about the Adopt OpenJDK BOF later in the evening.

So I went there. First it was Cecilia Borg, who spoke. She is product manager from Oracle and former JRockit and HotSpot developer. She is responsible for so to say facilitating from Oracle’s side the communities contributions to the OpenJDK. So, there is already a JIRA bug tracker set up (as presented by another prominent Oracle employee – Joe Darcy) and they expect to have soon test infrastructure and code reviewing tool.

To be honest, I expected something different from this BOF – a session on the whole bugathon process from finding what we want to fix to getting the source code, building it, doing a change, running the test suite and commiting it back. But anyway, not a big worry, I am glad that at least I know whom to approach and where to read if our JUG decides to embrace this idea.

Conclusion

It was a busy day at JavaOne for me, much busier in terms of conference sessions that I attended (I even went on two more, but I didn’t find it useful to blog about them). I will conclude this post with the quote of the day. This time it was Charles Oliver Nutter (the JRuby guy): “I don’t really know assembly language. But I fake it very well.”