Entries tagged with java

Entry tags:

Efficiency Expert

I am going through some code, cleaning up old constructs before a major release that's coming up. This takes me into some interesting places.

Today, I realized that there is a whole species of things that can be simplified by cutting out a lot of intervening code that is building unnecessary objects and doing unneeded lookups. I've patched a couple of places and will continue looking at the problem tomorrow.

Some of the fun, of course, is that we've moved up to Java 8 since this code was originally written which opens up all *sorts* of possibilities for playing with Java Streams. The amount of things that you can now do with one (longish) line of code is really impressive. :)

Entry tags:

Fortified

We've been running the Fortify app against our source code and the section that I'm responsible for has been pretty clean for the most part. But there was one set of routines (that I did not write) that was being stubbornly difficult in being changed to avoid an unreleased resource leak. I tried one approach (a poor one, as it turned out) that just broke everything in the area, so I backed it out and went after it again.

This time, I refactored the code to avoid the particular construct that causes Fortify to lose its mind as it scans our code. Once I did that, the code still worked, which was good.

And it passed the Fortify scan that just finished.

Yay, me.

Entry tags:

Spring Cleaning

It is amazing how deleting roughly 150,000 lines of obsolete code will improve the quality of your code base.

Entry tags:

Various Forms of Brain Damage

It's been that sort of day.

I spent much of the day at work trying to untangle some of my code that interacts with the Java UI. I have never worked with any of the Java UI code before last week and it is behaving in some extremely mysterious (and sometimes just outright weird) ways. I suspect I will end up sending an email later this weekend begging for an explanation of the weirdness, because I need to sort out the problem and move on. We'll see how that goes.

Meanwhile, I picked up my guitar during a compile and decided to play "The Boxer". My recollection is that playing it in the natural key of G has been causing me to bottom out on the low notes, so I dropped a capo on the neck to move the song up a full step to the key of A.

And then I proceeded to sing the whole song an octave up. Happily, it turned out that I *could* sing the song an octave up, but if I was going to do that, then why did I need the capo?

Brain damage. Clearly brain damage.

Entry tags:

Serialization Made Simple

This turned out to be really simple, but it was really difficult to find this as I was digging through the information on Jackson serialization, so I'm going to mention it here in case it's of use to anyone else.

I have some Java classes that are IDs that we cache so that (if everything goes right) everyone shares one copy of the immutable ID. They can all be represented as a Java String and there is a static valueOf() method in each ID class that either fetches a value from the cache or creates a new value in the cache if you're the first to request this ID. The toString() method generates the String from the ID.

So when you're serializing a bunch of JSON or XML, you want to write out the simple String representation and read in the String on the opposite side and then use it to fetch an ID from the cache instead of creating a new instance of the ID. It turns out that you can do this with just *two* Jackson annotations.

You tag the toString() method with the @ JsonValue annotation. This tells the Jackson framework that this is the only value that they need to serialize out to describe the contents of this class.

For the inbound side of the serialization, you tag the valueOf() method with the @ JsonCreator annotation so that the Jackson framework knows to call that method instead of a constructor.

Two annotations and it all works.

Cool!

Entry tags:

Enumerating It

Spent some time with one of the other senior programmers on Zoom today discussing the use of Java Enum values across multiple closely related classes and how best to structure this to avoid insanity. He gave me one approach, while I've simplified it a bit, I think, without penalty.

We'll see how this looks tomorrow morning.

Entry tags:

Ways of Making Progress

I had managed to exhume one of the necessary pieces of information using my superior Google-fu, so Gretchen was able to get on the phone with our financial advisor today and clean up one of the long-standing bits of financial business that needed to be taken care of. The right incantation was spoken and now all the various wheels are in motion so that the clean up will happen.

We are, of course, waiting to see if anything blows up in the process. :)

Speaking of things that blow up in the process...

So I'm writing a new feature at work where I'm using some of my older code to allow me to extract the data that I need to answer a lot of questions. It's actually working pretty well, but I got into a situation this afternoon where I was getting a null pointer exception. Ok, I had the data that I could pass in to clear up that null reference, so let's just initialize things and let them run normally.

A cascade of null pointer exceptions followed for a different object, because I had also passed in a null for the period identifier instead of the well-known (in this environment) "this is not a valid period" identifier. I added null checks. I added a lot of null checks.

And then I went back to my code and passed in the well-known "this is not a valid period" identifier instead of a null reference. Because suspenders *and* belt, right?

It's working correctly now.

Entry tags:

POJO Stuck

When I originally ported our code to Java, it was some years ago. One of the things that I wrote was a fairly robust class to support XML serialization which handled the various types that I wanted to handle as simple calls, burying the translation to and from Strings. It also knows how to detect and avoid duplicating multiple instances of the same object that are in the serialization stream. And it has a SAX-like callback method to allow the classes that it works with to read attributes and contained elements in any order that they are presented.

Overall, it's a nice class.

But Java moves forward and the Jackson libraries now support XML serialization using their own scheme. In this case, you add some simple annotations to the class and now you can read and write an object (Plain Old Java Object, or POJO) belonging to the class in XML as well as JSON.

I spent the last two days adding support for Jackson-enabled objects to my XML serialization library. This was relatively simple, because both my XML serialization library and Jackson's are built on top of StAX, which is a very nice XML streaming system. I had to make a few changes, because I had used the XMLEventReader and Jackson wanted the XMLStreamReader, but that mostly just required me to remove all of the peek() references from my code.

Today, the modified code passed all of the unit tests (and some new tests that I added for the occasion), so you can now read and write Jackson-enabled objects as part of my XML serialization scheme.

It's nice to have a quick win.

Entry tags:

Checking In

Did I mention lately how annoying I find checked exceptions in Java?

Today was particularly bad, as I was going over some very old code and removing a couple of checked exceptions that were no longer used from a method signature that is overridden virtually everywhere. Sadly, the IDE I'm using doesn't have a good way to clean that up, so I spent a lot of time doing trivial edits.

My eyes have now glazed over, but everything is compiling again...

Entry tags:

Back to Work

And it was back to work today.

Today's lesson was on yet another fine point of Java generics.

Crossposts: https://billroper.livejournal.com/1949232.html

Entry tags:

What's In The JAR?

I have been pulling my hair out trying to figure out why my XML reading code is misbehaving. I fix it in one place and it all works fine. Then I go to another project and the same code fails.

Today, I managed to convince myself (correctly) that the nice new unit tests that I wrote work in one environment, but not in the other. This is not a happy situation.

It turns out that my XML reading code that was "working" was only working because I had hacked it to work with an underlying XML reading JAR that was broken. With a correct version of an XML reading JAR, the hacked version won't work. You have to have the *correct* code on my side to make it work.

But, of course, the *correct* code will not work with the broken JAR.

I have given up and changed my XML reading code so it no longer uses the broken method in the broken JAR.

And now it works no matter which set of JARs gets loaded.

Blort.

All this talk of JARs is making me hungry. Maybe a jar of strawberry jam and some fresh rolls can be found. Or something like that.

Crossposts: https://billroper.livejournal.com/1947748.html

Entry tags:

XYZZY

I am in a maze of twisting JARs, all alike, except that some work and some don't.

Crossposts: https://billroper.livejournal.com/1939775.html

Entry tags:

The X-Refactor

I actually don't so much mind refactoring code, as long as I am doing something that will improve the code base. For instance, today I worked with one of my colleagues to convert a reference to a particular class to a reference to a shared interface implementation. This was good, because now anyone else who has the same problem will be able to implement the method on the interface and get the behavior that they want.

And then there is the refactoring that is just cleaning up after other people who have introduced references to other libraries in classes that simply shouldn't be using those libraries. This is much *less* fun.

At least the end is in sight.

Crossposts: https://billroper.livejournal.com/1879429.html

Entry tags:

Enumerating the Problem

I have become extremely fond of Java's enum types, because there are so many things that you can do with them that you can't do with the C++ enum types. I have managed to work around those differences, but it would be so much simpler if I didn't have to.

Crossposts: https://billroper.livejournal.com/1875700.html

Entry tags:

Work Gone Wild

Another round of fixes destined for an emergency patch that I spent most of the day hacking out with one of my co-workers. The code in the neighborhood is much cleaner now -- I wrote this fairly early in my Java adventure and was able to make a bunch of fairly trivial, but major improvements while cleaning up the bad behavior that was going on. And I managed to eliminate a lot of duplicate code, which is always a bonus.

It's passed our initial smoke tests to see if it has fixed all of the client bugs, so a build is underway and QE will have at it in the morning.

Chaos! It's what's for lunch.

Crossposts: https://billroper.livejournal.com/1874892.html

Entry tags:

Back to Work

And today was back to work (and school) after a two-week break. There were varying degrees of success.

On the other hand, I finally threw up my hands and stopped trying to add a remove method to my Java iterator built on top of my unifying interface layer. Instead, I've coded things using a different approach to what I'm doing.

I've managed to cobble together a first unit test to throw against the wall that found a couple of different (and one pre-existing) bugs and have fixed those. Now that the framework's in place, I should be able to write a lot more test cases fairly quickly to make sure that there aren't more bugs or, if there are, that I can fix them. :)

I have become fond of unit testing...

Crossposts: https://billroper.livejournal.com/1838045.html

Entry tags:

Refactoring

This was entertaining. I have ported a couple of thousand lines of my experimental code from C++ to Java. In the process, I've rearranged it so that many of the interesting objects are now members of enumerated types in Java, each of which knows how to write the encoded XML that the consumer of the objects wants.

Better yet, I've added a style class that allows me to stack those interesting objects together to control how our data will be displayed in the grid. And the style class knows how to write the encoded XML that the consumer of the objects wants as well.

What this means is that all of the little magic numbers that were embedded in our code have been sent off to live in my new enumerated types and the style class, so that when we want to apply a style to a cell, we can just apply it by name instead of having to remember the number for the particular style that we want to use here. Better yet, I can create a style, clone it, and then add a bold attribute to it and stick it into our style sheet.

This should make life *much* simpler.

Next week, I'll generate all of the necessary styles and plug this in and see how it works.

Crossposts: https://billroper.livejournal.com/1836108.html

Entry tags:

Comparative Programming Languages

It's time for another round of comparative programming languages, as I have suddenly inherited a chunk of C# code that needs work. Happily, C# and Java have a lot of similarities, except when they don't.

I spent a couple of hours this afternoon and managed to do a moderate amount of cleanup. There's another bigger thing I want to try on Monday -- because I am *not* going to try it this weekend. :)

Crossposts: https://billroper.livejournal.com/1834016.html

Entry tags:

Solving the Math Problem

So I've been trying to sort out a problem with one of my calculations and failing. The problem is that the calculation exists in both our C++ and Java code, but there's no UI to vary the inputs on the Java side, so it's really much more convenient to test this on the C++ side. Of course, we have no unit test framework for C++...

I ported all of the utility routines over to the Java side and wrote unit tests for them. Whenever I saw an error in the results on the C++ side, I'd go add another case or three to the Java tests, figure out what was going wrong, patch the Java code, patch the C++ code, and go run another case on the C++ side.

After a couple of cycles of this, everything worked.

*whee*

Crossposts: https://billroper.livejournal.com/1831688.html

Entry tags:

Boosted

Having spent a fair amount of time working with Java Maps, I am being inordinately annoyed by the idiosyncrasies of boost::unordered_map.

I'll fix the code tomorrow.