You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-dev@jakarta.apache.org by Markus Gaisbauer <ma...@gmx.at> on 2008/02/05 14:13:56 UTC
Why isn't ConstantPoolGen final?
Hi!
After my recent performance patch, I have further looked for code that
could possibly be speed by applying a few optimisations.
Although only a small percentage of total time is spend in ClassGen
initialisation (about 20% of deserialization and about 10% of combined
deserialization/serialization time), some speedup may be achieved here.
I was wondering why ConstantPoolGen isn't final, and why the fields
size, constants and index as well as the method adjustSize are
protected? Are there actually subclasses out there that depend on their
contracts implicitly defined by the current implementation?
cheers,
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Why isn't ConstantPoolGen final?
Posted by Torsten Curdt <tc...@apache.org>.
You never know what people did out there. No clue. Once it's open -
it's open.
The problem in changing it will mainly be backwards compatibility.
cheers
--
Torsten
On 05.02.2008, at 14:13, Markus Gaisbauer wrote:
> Hi!
>
> After my recent performance patch, I have further looked for code
> that could possibly be speed by applying a few optimisations.
>
> Although only a small percentage of total time is spend in ClassGen
> initialisation (about 20% of deserialization and about 10% of
> combined deserialization/serialization time), some speedup may be
> achieved here.
>
> I was wondering why ConstantPoolGen isn't final, and why the fields
> size, constants and index as well as the method adjustSize are
> protected? Are there actually subclasses out there that depend on
> their contracts implicitly defined by the current implementation?
>
> cheers,
> Markus
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org