billroper: (Default)
After getting the Java code to compile, I started trying to use some of the 48,000 lines of code that I'd ported for something other than serialization in and back out. This started showing up the places where I'd stopped the port and stubbed things out and where there are differences between the Java and C++ basic architecture that I'd planned when I started this many months ago.

I can now locate members of the Account and Time dimensions. I can't actually retrieve data yet, because that runs into a stub in the Account class, but I think I will refactor and delegate that problem to the data storage class that the Accounts contain.

And then all of this will start doing something hypothetically useful. :)
billroper: (Default)
At some point late this morning, I came to the horrible realization that the absence of the "const" keyword in Java, coupled with the absence of operator overloading, meant that all of the code that I was porting across from C++ had an ugly, ugly hole in it.

I have ID classes that I use to locate several types of objects in the C++ code. In C++, I would write code like:


const CPdID& id = pPd->GetID();
PdID modifiableID = pPd->GetID();


The first case wouldn't make a copy of the const reference that GetID() returns and I wouldn't be allowed to change it, while the second line would assign the contents of the const reference to my new PdID, since I'd overloaded operator=. And all was right with the world.

Except when I converted that to Java, I ended up with:


PdID id = pPd.GetID();
PdID modifiableID = pPd.GetID();


Now in this case, I have taken the reference that pPd.GetID() has returned that I did not want to modify and am happily going to modify it, because I didn't -- and couldn't -- define the function return as const. Ick.

So I have now made PdID immutable by removing all of the mutators that belong to the class. And I've added a MutablePdID which extends PdID and contains all of the mutators that are no longer in PdID. Add toMutable() and toImmutable() methods to each class that will create new objects as required, and my IDs Formerly Known As Const are now safe from the ravages of clueless coding.

The result looks like:


PdID id = pPd.GetID();
MutablePdID modifiableID = new MutablePdID( pPd.GetID());
// The case below is not preferred (by me), because if GetID() returned a MutablePdID,
// I could change the returned object without intending to. Oops.
//MutablePdID modifiableID = pPd.GetID().toMutable();


This was an exciting way to spend a day of work...

Back At It

Jan. 29th, 2014 10:16 pm
billroper: (Default)
Katie and Julie piled into the van with us and were dropped off at school this morning, resuming normal schedules. :)

In other news, I have been cleaning out the compilation errors in my Java port. The end is in sight, although the nasty tendency of JDeveloper to hide vast tracts of errors until something else has been cleaned up makes estimating how far I am from the end just a bit more difficult.

*sigh*
billroper: (Default)
It's just amazing how many compile errors you can pile up when you're frantically converting code and not even trying to compile, because the compiler only gives you the first hundred errors and most of those are due to functions that you haven't ported yet.

The number of errors is going down pretty quickly now, but it's a slog.
billroper: (Default)
Well, I thought that Apache MINA was going to solve my problem of wanting an expandable ByteBuffer. However, when I read another bit of the documentation, it seems they've decided that trying to solve their particular problem with an expandable ByteBuffer was a bad idea, so they'll be taking it out of the next major release of the project. *sigh*

So I will roll my own. It's not inherently that complex. It's just tedious.

Because I needed to be writing some more tedious code right now...
billroper: (Default)
I'm working on bringing the formula processor up in Java right now. This requires interpreting a byte array as a variety of different kinds of values, while keeping track of whether the byte array contains values in big endian or little endian order. ByteBuffer would seem like a fine choice, but it doesn't automatically expand as I write to it, nor does it retrieve all of the types of values that I'd like to store in the array.

Apparently, someone working on the Apache MINA project had the same warm thoughts about ByteBuffer and rolled their own extension, IoBuffer, which appears to do all of the things that I'd like it to do.

This makes me happy. :)
billroper: (Default)
So I'm still working on porting my code from C++ to Java. I'm over the 40,000 line mark now, which is good, but there is still a lot of stuff left to port. I've been working through the Var class for several days and am nearing the 6000 line mark there. (It's a large and important class with many methods.) And as I work down through it, I run into many other classes that aren't completed where I either go "I'll fix that later" or "I should go fix that now".

So I needed to copy an object that held an array of other complex objects that held still more complex objects along with a metric ton of ordinary data. And I was about to swear and write yet another copy constructor (because I am a recalcitrant C++ programmer apparently) when I suddenly realized that I was about to do way too much work.

If I implement the Cloneable interface and the clone() method on these objects, then I get a free bitwise copy of everything that they contain. So for that object with a metric ton of ordinary data, I just call super.clone() and I have now copied the metric ton of ordinary data and only need to fix up and clone the complex objects that I want to have new copies of, since my intent is to do a deep copy when calling clone().

So I ran around and implemented all of the necessary clone functions for half a dozen classes.

And the code base got 47 lines longer. Instead of a whole lot more lines of mechanical copying which would have pumped up the line count, but not actually done any more work.

Oh.

OK. I guess I'm not yet too old to learn some new tricks. :)
billroper: (Default)
With a few adjustments to get everything into alignment, my Java-based reader/writer for our old file format is working nicely. I managed to read a 90 MB file and write it back out so that the old application could successfully read it, so I'm going to count that as a success.

It is amazing how much faster the file writing got when I wrappered the FileOutputStream with a BufferedOutputStream. :)

I also managed to save about 7% (which was much less impressive, but nice to have) by fetching and storing the default constructor for the class and calling Constructor.newInstance instead of Class.newInstance.

Since I promised this bit of coding would be done this week, I'm feeling pretty good about it...

It Lives!

Nov. 6th, 2013 06:30 pm
billroper: (Default)
I can now read -- to a first approximation! -- the old binary format for our data in Java.

Next is to be able to write the format successfully, which will take a little bit longer, because some of the code that I copied in from the previous version of this didn't implement writing. I will need to add the necessary logic there.

And there are some classes that are missing in the test data that I'm working with that I'll have to test with some different data.

Later.
billroper: (Default)
In more ways than one.

Windycon starts setting up Thursday night and gets into full swing on Friday. I hope I'll see a lot of you there!

And I keep on pushing through new Java classes. Today, I successfully read all of the account-related classes, which is the vast majority of the classes that needed to be written. Sadly, not all of them.
billroper: (Default)
I can now read many of the classes in my binary file, but I stopped somewhere over 300 variables in due to a serialization error of some kind.

Tomorrow, I'll figure out which class has the bum instruction in it and see what fails next...

(The previous failure was because I forgot to declare one of my variables as static. *oops*)
billroper: (Default)
The set of Java classes that I'm working on are not yet complete, but I was able to read a chunk of the old binary file format successfully today. Of course, this required fixing a bunch of little buglets.

For example, Unicode characters on an Intel box in C++ are stored in little endian format. In Java, Unicode characters are stored in big endian format. All of the stored binary strings have to have bytes flipped both inbound and outbound. Also, Java does not have unsigned primitive types and the legacy binary format that I'm using makes extensive use of unsigned math when reading the data.

All of this makes life exciting. :)
billroper: (Default)
I am coding up Java classes at what seems like a tremendous pace. It is not a fast enough pace, but I am making progress.

The problem is that it's very hard to see the progress until everything is done.

*sigh*
billroper: (Default)
I'm shuffling the XML generation and reading code that I've been working on to try to produce an XML format that is more satisfactory to others in the group. Unfortunately, this requires a lot of cutting, pasting, and assorted editing. With any luck, I'll finish it up tomorrow and then I'll be able to see what I've got.

XML Hell

Jul. 10th, 2013 11:10 pm
billroper: (Default)
Everyone appears to have a different idea about what well-formatted XML looks like. This makes life entertaining.
billroper: (Default)
One more round of rearrangements on my Java code and the XML serialization logic that I've built on top of the StAX XML API seems to be working pretty well.

In other news, the new LJ home page is really ugly.
billroper: (Default)
I am gradually figuring out more and more about how to work with Java types, enums, autoboxing, and generics, which is important when you're doing inbound XML serialization, as you end up needing to create a lot of objects. I've written a bunch of little utility routines that keep my XML consistent and the resulting XML document is making successful round trips, which I find very encouraging.

Eventually, I will have written enough utilities to cover all of my current cases. Right now, I'm still at the stage where I go to serialize another class and go, "Whoops! Time to write some more serialization code..."
billroper: (Default)
I've now got a mostly-working XML serialization implementation in Java built on top of the StAX API. I have successfully written data out. Tomorrow, I will see if I can read it back in. :)

I know that there will be pieces of this and that which I'll be adding to the implementation for some time as I deal with different types of data. But it's a start...
billroper: (Default)
Today was spent working through the Cloneable interface and creating copy constructors for the various classes I've been working on. Despite various dire warnings that I found via Google about the problems with the Cloneable interface, it appears to be one that we're using around here, so I will just have to use it carefully. :)

In other news, I sent off an e-mail that may result in stress reduction. We'll see how that goes...

Behind

May. 15th, 2013 11:23 pm
billroper: (Default)
As Operation Learn Java In a Week continues, I'm getting behind on several things that I would rather not be behind on.

[livejournal.com profile] daisy_knotwise is going out of town to the Women's Drum Weekend that Sally is organizing. Maybe after Katie and Julie go to sleep...

(However, Gretchen advises me that when I'm out of town, the girls never go to sleep. This could be a flaw in my otherwise clever plan.)

Profile

billroper: (Default)
billroper

October 2025

S M T W T F S
    1234
567891011
12131415161718
19202122232425
262728293031 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 2nd, 2025 02:06 pm
Powered by Dreamwidth Studios