Today's assignment is MyISERN-1.2.
All tasks completed.
Group Process
My partner Kevin English really got into the text interface on this assignment. We had already divided it up on a previous assignment so that he was doing the interface, but on this one he really seemed to have a vision of how it should work. He volunteered to do all the data inputting, so he was writing code for himself to use.
I tried it out a little, and it is a nice interface. It's actually menu-driven rather than command-driven and pretty intuitive1.
As far as working together, we mostly did what we've done on past assignments: meet as often as we can, kick some ideas around, and then decide what we'll do until the next meeting. Since I'm writing the model, a lot of the group interaction has been about what methods my partner needed me to implement.
Difficulties
The main difficulty we had was with JAXB and Java. Every time we've used it, we've thought about wrapping JAXB somehow, but we never did. The problem is that we couldn't find a way of wrapping it that would solve the problems we were having without being more work than the problems themselves.
For me, working on the model, the problem manifests as doing things three times. For Kevin, it was probably different.
When we first started using JAXB, I thought maybe we could just wrap or convert the three JAXB objects into things that formed an inheritance tree. But there was really only one method they had in common. The problem was that they had many repeated methods which were analogous but not identical in type or number.
Kevin has his own take on the problem, but I look at it this way:
Java doesn't let you merge, or even blur the line between, object structure and metadata. Objects can't easily inspect each other's structure and interact based on what they discover. It's also very rigid about types. JAXB, on the other hand, converts XML entities with children to classes with fields. The sum is that you lose the ability to treat the structure of the data as data that can direct the code. Instead, it's an invisible (to the objects) structure that you must hard-code the objects to synchronize with.
To really get around that, as far as I can see, the wrapper would have to be a sort of reverse-JAXB that turns the JAXB objects back into some type of self-describing data structure like a DOM tree or nested maps of strings.
That never seemed worth the effort, so we would always sort of daydream about having a solution and then keep going without it2.
I'm interested to see what other groups have to say about JAXB. I keep going back and forth between thinking there must be wonderful way around it that I just haven't figured out yet and thinking that Java and JAXB are just hopeless.
Another minor thing is that our code coverage suddenly dropped right near the end. From the reports, it looks like everything has pretty good coverage except for some enums and our old command-line interface, which is coming in at under 60%. I knew that my partner was still using parts of the command-line interface to work with the new interface, so I figured he had merged or moved the test code in some way that caused it to only test the things we're actually still using.
In any case, the sudden drop didn't seem to be caused by a whole bunch of new, untested code. I also didn't notice it till my parter was asleep, so I didn't hold up the release for it.
Next Time
Next time, we might want to do a little more of the "skeleton" of the project earlier: things like issues, unit test, and wiki pages. We sort of lost track of where we were and what was left to do, and I think that would've helped.
-
It has a little bit of old code that I wrote in the first iteration for displaying tables. Right at the last minute, that old code started choking on nulls.↩
-
We didn't realize it until the very tail end of this assignment, but there's also a problem with JAXB and null. JAXB uses null in a lot of places where an empty collection would make more sense. If I'd known how pervasive that was, I might have gone ahead and written a wrapper even if that was the only thing it fixed.↩
2 comments:
Interesting issues! I don't understand exactly what you guys wanted to do, but there is both metadata for Java (the Class class) and metadata for XML (XMI).
There are also other ways to manipulate XML in Java (for example, JDOM), which have different kinds of strengths and weaknesses than JAXB. I guess it might be possible that in some scenarios using something other than JAXB might be preferable. I used to use JDOM, which provides you with a "less typed" version of the XML tree. That is good in some ways and bad in others.
Ironically, soon after I read and responded to your entry, I spent 20 fruitless minutes trying to figure out how to get JAXB to generate a class implementing Comparable so I could use its instances in a TreeMap. Argh! :-)
Post a Comment