Bill Roper's Journal

Finished up the Java code for a fix I was making and fired things up so I could see how it was working. Opened up a model to give it a try.

It was *then* that I realized that the UI for this feature has not yet been ported to Java. It's still in C++ only.

Of course, I haven't ported my code to the C++ side yet. And one library that I was using that made it simple to write a particular routine I need doesn't have any C++ equivalent. I can write the necessary code to do what I need done, but it will take a little time to get it right.

So we'll see how this works next week.

*sigh*

It lives! My Frankenstein's Monster of code lives!

Now, I just need to figure out how to debug it.

I am working on changing the way that we handle renaming of account IDs in our product. This might seem simple, but there are a great many account IDs stored in many, many different records, all of which need to be switched over to use the new system.

And when I finish doing this in Java, I get to do it again in C++.

*sigh*

For someone who doesn't actually know C#, the port of this chunk of my code from Java to C# is going quite well. I think that I'm likely to finish the whole thing up tomorrow unless something goes horribly wrong.

The biggest chunk of time was spent sorting out the differences between a Java iterator and a C# IEnumerable interface. Other than that and a few scoping issues, things are going pretty well.

We'll see what happens next. :)

So I wrote a new method for the project that I've been working on. It wasn't an overly complex method, but it was slightly annoying to write and might actually have been written in some "doomed to fail" way by mistake, so I said to myself, "Well, self, why don't you just write a unit test and make sure that it works?"

This was a good question with a simple answer, so I wrote the unit test. After a bit of futzing around with types (generics were in play), I got the unit test to work and determined that the new method was putting out what it was supposed to given the inputs I had given it. Good enough.

Let me go add it to the list of unit tests so that it will get run when I check this mess in again.

Hey, as long as I'm adding the unit test to the list, let's run the subset of unit tests that exercise my code.

Why are these unit tests failing?

It turns out that I had made a change that converted an ISO currency code I was using from upper case to lower case. This would seem harmless and -- in some better universe -- it would be. However, the Java Currency.getInstance() method stubbornly insists that it is only going to play nice if the currency code is in upper case.

I have patched the code so that the currency code is now upper case again.

Sheesh.

So much to my surprise, a unit test has done what it was supposed to do. This is a first in my experience...

I have nearly finished a big change to the Java code base. Unfortunately, as I near the end of the process, I realize that I am going to need to make a similar change to the C++ code base.

Sadly, changing the C++ code base is a much more annoying process.

Ah, well.

I built a new JUnit test framework using JMockit and now have a good place to stand to write lots and lots of unit tests as I build out my new code.

This makes me happy. It makes my bosses happy too, which is also a good thing.

Things should be simpler.

Because a chunk of our application is still coded using an obsolete library that is not supported by modern versions of JDeveloper, we are mired on an older version of JDev. This means that the standard methods for installing JDeveloper extensions don't work, because the website that you'd get the updates from has been retired. But there is a place that you can go to get JDeveloper extensions for older versions of the development system, assuming that you can find it, and then you can download the package to your local hard drive and install it from there.

Because we had upgraded to a slightly newer version of JDev a while back, all of the extensions that I had loaded into the older version were no longer available. And I needed the extension that would allow me to run JUnit tests from inside JDev so that I could do some fresh test development. This resulted in my swearing, finding the package I needed, downloading it, and discovering that the package wouldn't install.

You see, the package insisted on having a particular *exact* version of JDev to install against and *our* version of JDev has been patched with some fixes, so it is slightly newer than the version that the package wants to install against. This is now starting to tick me off.

Well, the package to install is distributed as a Zip file, so let's open it up and see what's inside it. Ah, there's a likely looking XML file. Let's see what's there. Yup, there are the oldest and newest versions that you can install against. Let's bump that newest version up to the same one as mine, zip the archive back up, and see how this works.

Happily, it did and I can now run JUnit tests again from inside JDev.

As I said, things should be simpler.

We had some code that was running slowly across a list of some 20K members. It turns out that the reason it was running slowly was that rather than just adding new members, we checked each member of the list to make sure that we weren't adding a *duplicate* member with the new add. This works fine for short lists, but is pretty much abominable by the time you're adding 20K members.

"Well," I said to myself. That's easy enough to fix. I can just add a hashCode() (and matching equals()) method to the class for the members that are being added to the list; then add a HashSet to keep track of what's already in the list, because that will look things up in a hurry. In fact, we should just make a class that welds a HashSet to the side of our ArrayList, because I know I've solved a similar problem before and we may as well not have to *keep* solving it."

I then paused and ran a brief search.

Right. ListOrderedSet in Apache Commons. I figured someone else had had this problem before...

Did I mention how nice it is to be working in a language with modern libraries available?

Ah, there's nothing like going back to work on a section of the Java code that I haven't played with in a year or so. Now how does this work? :)