Cool, just figured out the Heap walker part of JProfiler :) Never had a need to before.
Anyways, my maintenance 'improvement' basically doubles the size. Old MutableInteger wrapping an int is 16 bytes in size. New MutableInteger wrapping a Number via superclass is 2 x 16 bytes in size. Will go ahead and roll it on back. Hen On Mon, 21 Jun 2004, Henri Yandell wrote: > > I plan to do this by Saturday. I want to try them out in JProfiler to see > what the actual differences are, more for my own education than because I > think there will be a surprising result. > > Just in case you wonder about nothing happening. > > Hen > > On Mon, 21 Jun 2004, Henri Yandell wrote: > > > > > Jar size isn't important, maintainable code size is why I suggested moving > > to storing the value in the abstract. > > > > Am happy to rollback if that is desired. > > > > Hen > > > > On Mon, 21 Jun 2004, Stephen Colebourne wrote: > > > > > I've only now got a chance to review this (holiday ;-). > > > > > > I am less than happy with the current CVS code as it involves storing each > > > subclass as an Object. IMO, the whole point of this package is to create > > > classes that hold each value as a primitive, as per the java lang Number > > > subclasses, and [lang] Range classes. > > > > > > I know that this creates more code in the jar, but that is irrelevant next > > > to the new Integer() or new Byte() etc in the constructor of the CVS code. > > > Creating these additional objects is a memory hog and bad for the gc. I can > > > see no advantage other than jar size for the CVS code, hence would -1 the > > > current CVS. > > > > > > I haven't checked if this was how the classes were originally. If so, can we > > > rollback? > > > > > > Stephen > > > > > > ----- Original Message ----- > > > From: "Henri Yandell" <[EMAIL PROTECTED]> > > > > First thought when looking at the code is that we could simplify things > > > > with a protected Number in MutableNumber, and move the intValue etc > > > > methods up into MutableNumber. > > > > > > > > The getValue/ setValue(Object) can go up too, and all that would be left > > > > in the mutable subclass is the primitive override and the constructor. > > > > > > > > Pro: Less code in the subclasses. > > > > Con: A protected rather than private variable. More memory is taken up > > > > with the mutable part being an Object and not a primitive. > > > > > > > > Just a thought. > > > > > > > > Hen > > > > > > > > On Thu, 10 Jun 2004, matthew.hawthorne wrote: > > > > > > > > > I just made a checkin of some initial code for mutables. I haven't used > > > > > CVS in > > > > > a few months now (switched to subversion) so let's hope I didn't screw > > > > > anything up. > > > > > > > > > > I have to admit that I haven't looked at this code for a good time, > > > > > since around > > > > > August maybe. So all are welcome to take a look and make improvements. > > > > > I don't really have a solid use case for these classes anymore, so I'd > > > > > imagine > > > > > that others will have a better insight in that regard. > > > > > > > > > > The test coverage is pretty good, I think in the 70% range. I remember > > > > > learning > > > > > some weird things about the way Java handles primitive number > > > > > conversions, as > > > > > I was trying to get the tests to pass. If something looks bizarre give > > > > > a yell and > > > > > I'll investigate. > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
