I’m gonna keep this one short, at least for now. You know the reason.

Last week, we decided to replace the Joda Time library with java.time and ThreeTen-Extra library. And that’s exactly what I did this week.

The Migration

There were 3 steps to what I did.

1. Identifying the replacement classes.
2. Understanding the class structure to start the migration from the base classes.
3. Figuring out the best match for a given instance of replacement.

It might not look like much, but there was quite a bit of work once I got into it. I had already started off the replacement without much thought in the previous week. But as I later realized, it’s better to first look exactly where and how the base classes are used later.

Identifying the Replacement classes

The first step was figuring out which class of Joda Time maps to which of java.time or ThreeTen-Extra (henceforth known as TTX). Some of the classes like DateTime could be replaced with ZonedDateTime from the built-in library, while others like Interval needed the help of TTX.

There were some concepts like Hours, Minutes etc. that were replaced with Duration and Period. These were used in some calculations of the scheduling algorithm.

Understanding the class structure

It’s so much easier to start from the base classes and replace the library from inside out. This is because of our lovely IDEs that continuously parse the classes and perform semantic analysis to see if we’re using methods correctly. This is quite useful as then we can clearly see if and when we’re using a method wrong somewhere, use the IDE to suggest replacements and continue our work happily.

More importantly, it helps to understand why a particular type was used in the first place. Then I can make an informed decision for the next step.

Figuring out the best match

You can’t just blindly start replacing Joda Time with whatever fits. You need to look into the context. What’s the best way to replace DateTime used in an instance where it’s used to record the available times of an operation theater? I could go with a ZonedDateTime, or use a LocalDateTime that dropped the timezone. Heck, I could record them in Instants.

For recording the available times, I went with LocalDateTime. That’s because the available times are mostly for the scheduling work done locally. I could just add a timezone later if someone from Brazil wants to see when an operation theater in Rwanda operates.

What else? Oh yeah, we talked more about moving to an official repo under OMRS. It was agreed that it’s best to move at the end of the summer, when we have a concrete, ready-to-deploy module that others can also work on. So how could I show the world that I was working, making a contribution to the open source world, with those all-important green boxes on my GitHub profile?

I could make my fork into a standalone project! Just had to contact GitHub Support center. A kind lady there resolved the issue in hours. ?

That’s it for last week. I hope you’ll excuse the brevity, at least for now. Do check out the repo and comment on my choices. Please, I may have made mistakes. You get the joy of pointing out mistakes, I get some of dat free code inspection.

Until next time, peace!