I’ve been contemplating compile time bytecode manipulation for the Object Mapper Framework for a while now. Compile time instrumentation of classes seems to be a better approach and does away a whole lot of class loading issues, especially in OSGI environments. In any case, I remembered Project Lombok and reading about JSR-269, which was introduced with Java 1.6. It’s an API that allows you to plug custom annotation processors into javac.

After experimenting and reading a bit, here is my reading list:

Over the years I have always been fan and user of the Eclipse platform. I liked the openness, the available plugins, and many of its features, including the CTRL-1 hotkey that does everything, and a few other things. However, over time Eclipse got slower and slower, more unstable, and after a while just a pain to use, especially when using more than one screen. I decided to give IntelliJ another try, as I’ve done a few times before. And like every time I tried it, I got really frustrated. IntelliJ and Eclipse differ in certain areas, and my inability to use the old shortcuts just made me feel like an infant on stilts. However, after more encouraging tips from Reddit and other research, I installed the Key Promoter Plugin which shows an angry popup whenever you use the mouse to do something that has a shortcut. With that, I’m learning keyboard shortcuts quite fast…

Just downloaded Eclipse Kepler and I’m quite happy with it. It appears fast and stable so far, but that could be just that it’s a brand new install. Anyways, I re-added some of my usual code templates and while doing so, I discovered a few useful things. And because I keep doing this on every Eclipse installation, I decided to write this down here. On a related note, an Eclipse plugin to share your Eclipse templates would be pretty rad. But I digress.

In my career as a software developer, I’ve come to appreciate the principles of Continuous Integration (CI). It forces you to do the hard things early and often and thus helps you reduce risk during development. It forces you to write tests, and be responsible about what you check in. All in all, good qualities and something that every development team should aspire to. Or so I thought. Reality is different, and so far almost every development team I have interacted with is deadly afraid of doing CI. So much, that there’s been near-mutinies because CI and what it means for team, causes so many problems. This is something that puzzles me, and I realize it might be because the teams in question don’t fully understand what CI is or only realize a subset of what it means. This is my attempt to demystify and explain CI.

A while ago LinkedIn introduced what looked like a really cool feature, an easy way to “endorse” skills of your contacts. It’s really easy to go in and click “Endorse” on a bunch of skills. However, one thing that kept surprising me was who endorsed what skills. For example, just today I had a ex-coworker from over 4 years ago endorse me for Hibernate. Which by itself is a nice gesture, only thing is, he’s an art director. I don’t want to be pretentious, but I would believe that he knows as much about Hibernate as I know about Photoshop filters or fine arts. As a matter of fact, I usually get yelled at for my choices of colour. If he would have endorsed me for “Teamwork” or “Attention to Detail” or something like that, I would agree that it is an accurate representation of my skills. But getting endorsed for my Java ORM skills by a designer doesn’t constitute valuable feedback.

I’ve had the idea for this blog post in my mind for a long time. It is based on all my personal experiences and observations over the past years and is in no way scientific. It is my personal opinion, and even though this is how I perceive the world, it might not be true for other people. With that said, let’s jump to the core of things.

A happy developer is a productive developer.

Now here’s something I didn’t know: XSLT 2 and XPath actually support date arithmetic! Took me a while to figure it out, but here’s how it works.

First, all your dates will have to be in ISO-8601 format. For dates only it looks like this: YYYY-MM-DD and for dates and times, like this: YYYY-MM-DDTHH:mm:SS.sssZ. There’s a few other formats, but these are the ones that probably cover all use cases.

In order to make use of all the functions regarding date and time, the values will have to be converted into the appropriate types. They data types are defined in the XMLSchema namespace http://www.w3.org/2001/XMLSchema and are:

Introduction

I’ve been trying to get Google Guice and Peaberry to work in my OSGI projects for a while. Google Guice is a great dependency injection framework, and Peaberry promises to bridge the gap between OSGI services and dependency injection.

However, getting Peaberry to work was not trivial, mostly because there aren’t many docs and the quality of the docs is somewhat lacking. The best piece is still this pdf Peaberry - blending services and extensions, but it’s a lot of information in very little space.

Yesterday I ran into a most strange error when compiling one of my OSGI bundles:

[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.7.4:scr (generate-scr-scrdescriptor) on project XXX: A type incompatibility occured while executing org.apache.felix:maven-scr-plugin:1.7.4:scr: com.thoughtworks.qdox.model.Annotation cannot be cast to java.util.List

I saw several variations of that error and was initially clueless as how to fix it. However, I eventually found the problem:

@Service(value = { MyService.class, ManagedService.class })
@Component(immediate = true)
@Properties(@Property(name = "foo", value = "bar"))
public class NissanAutoDataUrlGenerator implements ManagedService { }

The mistake is that the @Properties annotation takes an array as it’s parameter. Eclipse does not mark the above as an error, however, the Maven plugin is not happy about it. Here’s the correct code:

I’ve been working on a small Java application I wrote a few years ago for some bug fixes and in the process of making it better, I introduced Google Guice, my favourite dependency injection framework. On of the great features of Guice is that it supports different scopes for injection. Per default, Guice will return a new object for every request. But sometimes you want to objects to be created a bit less liberally, for example, you want a certain object to be created only once. Guice has a @Singleton scope for that. Want an object to be created once for a request? Guice and guice-servlet offers @RequestScoped and SessionScoped. But there’s more, need JUnit per test scope? Guiceberry has exactly that: @TestScoped that will make sure every test gets exactly one object.