You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "matthew.hawthorne" <ma...@apache.org> on 2004/06/11 04:37:23 UTC
[lang] mutables
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
Re: [lang] mutables
Posted by Henri Yandell <ba...@generationjava.com>.
On Sat, 12 Jun 2004, matthew.hawthorne wrote:
> Henri Yandell wrote:
> > The constructor for MutableNumber is odd.
> >
> > It's
> >
> > a) Empty, so possible to have a MutableNumber without a value yet.
> > b) package-scoped, so only we can extend it.
> >
> > I'm not sure if there are good uses for a), but b) seems like something we
> > don't need to do.
>
> I guess I didn't think that anyone would want to create a MutableNumber,
> they would opt for the more specific MutableInteger, MutableFloat, etc.
I don't think they would either, though it is feasible I guess so not
worth making the class abstract.
I meant that the package-scoped constructor meant that people can't add
empty constructors to subclasses.
> But if that's not the case, then the package scoping is too restrictive and
> should be changed to public. The default (empty) constructor doesn't
> make sense to me either, maybe it was just an oversight.
Easy to kill.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] mutables
Posted by "matthew.hawthorne" <ma...@apache.org>.
Henri Yandell wrote:
> The constructor for MutableNumber is odd.
>
> It's
>
> a) Empty, so possible to have a MutableNumber without a value yet.
> b) package-scoped, so only we can extend it.
>
> I'm not sure if there are good uses for a), but b) seems like something we
> don't need to do.
I guess I didn't think that anyone would want to create a MutableNumber,
they would opt for the more specific MutableInteger, MutableFloat, etc.
But if that's not the case, then the package scoping is too restrictive and
should be changed to public. The default (empty) constructor doesn't
make sense to me either, maybe it was just an oversight.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] mutables
Posted by Henri Yandell <ba...@generationjava.com>.
Cool. Practically done it, but getting a unit test failure for the
testPrimitiveAccessors. Will figure out and submit.
The constructor for MutableNumber is odd.
It's
a) Empty, so possible to have a MutableNumber without a value yet.
b) package-scoped, so only we can extend it.
I'm not sure if there are good uses for a), but b) seems like something we
don't need to do.
Hen
On Sat, 12 Jun 2004, matthew.hawthorne wrote:
> Henri Yandell wrote:
> > 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.
>
>
> I think the pro of simpler code may be bigger than the con of memory loss.
> Those involved in hardcore performance tweaking may disagree. For me,
> the mutable classes were more about the added functionality than the savings
> in memory, so I'm in agreement with you here.
>
> ---------------------------------------------------------------------
> 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
Re: [lang] mutables
Posted by "matthew.hawthorne" <ma...@apache.org>.
Henri Yandell wrote:
> 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.
I think the pro of simpler code may be bigger than the con of memory loss.
Those involved in hardcore performance tweaking may disagree. For me,
the mutable classes were more about the added functionality than the savings
in memory, so I'm in agreement with you here.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] mutables
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> 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.
As I expected, but my main concern is that 2 objects takes twice as long to
gc as 1.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] mutables
Posted by Henri Yandell <ba...@generationjava.com>.
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" <ba...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] mutables
Posted by Henri Yandell <ba...@generationjava.com>.
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" <ba...@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
Re: [lang] mutables
Posted by Henri Yandell <ba...@generationjava.com>.
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" <ba...@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
Re: [lang] mutables
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <ba...@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
Re: [lang] mutables
Posted by Henri Yandell <ba...@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