Rearrangements
Apr. 30th, 2014 10:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
billroperSo I've got the clock opened up and spread across the floor on my work computer as I try to rearrange some of the very early utility code that I wrote in Java to be a good bit cleaner than my original implementation. This means that pretty much nothing was compiling.
But one of my co-workers is working on some code using my new request factory on his machine, so I've been updating the various classes that it needs and checking them in so that he can get what he needs. Since this is the first field test of the request factory, it's not surprising that I needed to update it.
And then I discovered that some of the XML that we're being sent is in nothing like the format that I'd expected. I figured out how to work around that, but in order to do it, I need to change the two functions that read the XML for an object (one for attributes; the other for embedded elements) so that they return a boolean value to indicate whether or not they've processed a particular attribute or element. (Before this latest development, a void return had been just fine.)
Almost every object implements the XMLSerialize interface that I wrote, which means they define the XML reading functions, which mean that they all need to return a value that they didn't return before, so they all have to be modified.
Each compilation in JDeveloper will find exactly one file that lacks the return values.
It strikes me that this is a sub-optimal approach to compilation...
But one of my co-workers is working on some code using my new request factory on his machine, so I've been updating the various classes that it needs and checking them in so that he can get what he needs. Since this is the first field test of the request factory, it's not surprising that I needed to update it.
And then I discovered that some of the XML that we're being sent is in nothing like the format that I'd expected. I figured out how to work around that, but in order to do it, I need to change the two functions that read the XML for an object (one for attributes; the other for embedded elements) so that they return a boolean value to indicate whether or not they've processed a particular attribute or element. (Before this latest development, a void return had been just fine.)
Almost every object implements the XMLSerialize interface that I wrote, which means they define the XML reading functions, which mean that they all need to return a value that they didn't return before, so they all have to be modified.
Each compilation in JDeveloper will find exactly one file that lacks the return values.
It strikes me that this is a sub-optimal approach to compilation...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-05-01 09:44 am (UTC)Err... isn't that what include files are for? define it once and include it where needed, then you only need to alter one definition.
no subject
Date: 2014-05-04 06:53 pm (UTC)But the problem in this particular case was that I changed a method so that it no longer returns void, but rather boolean. Since I'd already put the overriding methods into each of the classes (although I hadn't filled them out), each of them had to be changed to return a "false" value, since they aren't processing anything yet.