Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Mon, 21 Jun 2004 19:59:36 -0400 (EDT)
From: Henri Yandell <bayard@generationjava.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [lang] mutables
In-Reply-To: <Pine.LNX.4.44.0406210835120.9683-100000@orinoco.flamefew.net>
Message-ID: <Pine.LNX.4.44.0406211957510.17851-100000@orinoco.flamefew.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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" <bayard@generationjava.com>
> > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org