You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Matt Smith <ms...@dorado.com> on 2002/12/17 09:03:14 UTC
[BeanUtils] MethodUtils caching
I'm looking for a way to speed up some of my uses of Digester, and SetNextRule heavily relies upon MethodUtils.invokeMethod. What I've seen is that most of the time spent in getMatchingAccessibleMethod, and in particular in Class.getMethods(). Most of this is wasted work, since it's pretty much always the same class and paramType list being used for any particular instance of SetNextRule. So I'd like to cache the results of getMatchingAccessibleMethod, but it's private, making it a cut & paste job to do so. I can do that if I have to, but I was wondering if there is any code out there that is currently doing this type of caching already, of if you guys can tell me a better way to deal with this. I'd like to continue to benefit from updates to BeanUtils without re-copying code every time.
-Matt
Re: Trying to enable usage of commons within applets (was Re: [BeanUtils] MethodUtils caching)
Posted by Paul Libbrecht <pa...@activemath.org>.
On Mercredi, déce 18, 2002, at 11:24 Europe/Brussels, Jerome Lacoste @
BBC wrote:
> I am perhaps completely out of understanding here, but it seems that
> XDoclet(*) could be used there. You tag the classes that are supposed
> to NOT work in applet/sandbox environement and there are automatically
> documented as such. All other classes are automatically tested under
> the 'Sandbox test environment'. And failures are reported.
So it would be something like:
- let developers mark as applet-friendly (signed/non-signed) their
classes
- letting then jUnit running all the tests that have this XDoclet tag
so as to validate (to the extend of the test reach) this
applet-compatibility.
That looks good. Is it something easily doable within Maven ?
(doesn't this involve parsing/traversing the XDoclet result ?)
Paul
Re: [BeanUtils] MethodUtils caching
Posted by "Jerome Lacoste @ BBC" <la...@altern.org>.
Paul Libbrecht wrote:
> Having tests within applets looks perfect to me!
>
> The most simplistic approach would be to use appletviewer to run all
> the jUnit tests. That would bring an amount of "failed" that would
> force developers to flag their tests to be applet-friendly or not,
> then presumably flag the functionalities as such.
>
> A better approach would be to run a webserver and have the applets
> from there, I presume. Also, I am not a signed applet should not be
> tested as well (i.e. I am not sure there is not a little bit of
> security left within these which is again different from the simple
> java command).
>
> Or... should we make an interace for jUnit tests "applet-friendly" or
> such?
> I think the issue to manage here is close to a documentation/build
> issue: it needs to be documented what is applet friendly and what is
> not, and this has to be documented at least on a class-basis,
> cascading through dependencies). Would there be a better approach than
> just attacking unit-tests for this ?
>
> How much "unfriendly" to developers would this be ? I typically fear a
> complete refusal: "This collection is not applet-friendly, period,
> don't bother me with that..."
I am perhaps completely out of understanding here, but it seems that
XDoclet(*) could be used there. You tag the classes that are supposed to
NOT work in applet/sandbox environement and there are automatically
documented as such. All other classes are automatically tested under the
'Sandbox test environment'. And failures are reported.
Jerome
(*) Warning I know nothing about XDoclet, just read a small article
about it.
Re: [BeanUtils] MethodUtils caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Having tests within applets looks perfect to me!
The most simplistic approach would be to use appletviewer to run all
the jUnit tests. That would bring an amount of "failed" that would
force developers to flag their tests to be applet-friendly or not, then
presumably flag the functionalities as such.
A better approach would be to run a webserver and have the applets from
there, I presume. Also, I am not a signed applet should not be tested
as well (i.e. I am not sure there is not a little bit of security left
within these which is again different from the simple java command).
Or... should we make an interace for jUnit tests "applet-friendly" or
such?
I think the issue to manage here is close to a documentation/build
issue: it needs to be documented what is applet friendly and what is
not, and this has to be documented at least on a class-basis, cascading
through dependencies). Would there be a better approach than just
attacking unit-tests for this ?
How much "unfriendly" to developers would this be ? I typically fear a
complete refusal: "This collection is not applet-friendly, period,
don't bother me with that..."
Paul
On Mercredi, déce 18, 2002, at 01:27 Europe/Brussels, Rodney Waldhoff
wrote:
> Pressure from applet-oriented clients (like you) is one good way to
> address this. Perhaps adding a some sort of unit testing framework for
> running regular Junit tests in a "secured" mode would be another. I'd
> be
> willing to experiment with the latter if anyone else would like to
> collaborate.
Re: [BeanUtils] MethodUtils caching
Posted by Rodney Waldhoff <rw...@apache.org>.
On Wed, 18 Dec 2002, Paul Libbrecht wrote:
<snip/>
> I think the issue is simply related to the fact that much (too much?)
> of the jakarta development is interested to the server things and too
> few to the user-interfaces... I think, however, that such small utility
> classes like the commons should really think twice before going happily
> into security-breaking and should document their inability to run as an
> applet.
For what it's worth, I think it's more often the case that the developers
generally don't try to run the code in a "secured" or "sandboxed"
environment like an applet, and hence unintentionally "go happily into
security breaking". Clearly, documenting that applets aren't supported
isn't the best solution, supporting applets is. In most cases if someone
points out "don't do that, it's not applet friendly" the developer will
gladly implement an alternative solution or at least provide some sort of
workaround. It's just that in general the devloper is unaware of the
issue.
Pressure from applet-oriented clients (like you) is one good way to
address this. Perhaps adding a some sort of unit testing framework for
running regular Junit tests in a "secured" mode would be another. I'd be
willing to experiment with the latter if anyone else would like to
collaborate.
- Rod
> Thanks.
>
> Paul
>
Re: [BeanUtils] MethodUtils caching
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tuesday, December 17, 2002, at 11:23 PM, Paul Libbrecht wrote:
<snip>
> I think, however, that such small utility classes like the commons should
> really think twice before going happily into security-breaking and should
> document their inability to run as an applet.
this issue arises since reflection in java 1.3 is badly broken. some of
the workarounds rely on security breaking to work properly :(
on the other hand, this should have been written in a robust and fail-safe
fashion. so, if security bending fails then the beanutils should
gracefully fall back to the straight call. that way, if your JVM isn't
bust, you can still use beanutils in an applet.
you're right that this does come down to testing. it should be possible to
set up security that is identical to that in an applet without actually
having to run in an applet, shouldn't it?
and thanks for bringing this up.
- robert
Re: [BeanUtils] MethodUtils caching
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 18 Dec 2002, Paul Libbrecht wrote:
<snip/>
> I think the issue is simply related to the fact that much (too much?)
> of the jakarta development is interested to the server things and too
> few to the user-interfaces...
That has a lot to do with the Jakarta mission, which states that Jakarta
is "charged with the creation and maintenance of commercial-quality,
open-source, server-side solutions for the Java platform". See:
http://jakarta.apache.org/site/mission.html
Now, I'm all for trying to accommodate client applications as well, where
that makes sense, but you should hardly be surprised when the development
focus is on the server-side. ;-)
--
Martin Cooper
> I think, however, that such small utility classes like the commons
> should really think twice before going happily into security-breaking
> and should document their inability to run as an applet.
>
> Thanks.
>
> Paul
>
>
> On Mardi, déce 17, 2002, at 19:39 Europe/Brussels, robert burrell
> donkin wrote:
>
> > i'm a bit confused by this. care to expand?
> >
> > - robert
> >
> > On Tuesday, December 17, 2002, at 11:05 AM, Paul Libbrecht wrote:
> >
> >> Possibly opposed to this requirement, I would insist that BeanUtils
> >> may sometimes be used with Applets. Maybe a switch is useful, maybe
> >> there is a fast method towards everything...
> >>
> >> Paul
> >>
> >>
> >> On Mardi, déce 17, 2002, at 09:43 Europe/Brussels, Stephen Colebourne
> >> wrote:
> >>
> >>> MethodUtils is currently being reworked in [lang]. Hopefully the new
> >>> version
> >>> there can include some level of caching.
> >>>
> >>> Stephen
> >>>
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:commons-user-unsubscribe@jakarta.apache.
> >> org>
> >> For additional commands, e-mail:
> >> <mailto:commons-user-help@jakarta.apache.
> >> org>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Re: [BeanUtils] MethodUtils caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Sorry, I was indeed quite unprecise...
The story starts with JellySwing: an irreversibly attractive way of
building User-interfaces. And of course, as a good UI, you try to run
this as an applet (we really intend it).
However Jelly Swing uses BeanUtils and which in turn uses MethodUtils.
And here we break: MethodUtils was using Class.getDeclaredMethods()
which, for some reasons, is considered dangerous. We readily replaced
this with Class.getMethods() (at the possible expense of something I
presume) and it worked...
Similar security exceptions arise when commons-lang (I think) allows
itself to use a plain "System.getProperties()".
I think the issue is simply related to the fact that much (too much?)
of the jakarta development is interested to the server things and too
few to the user-interfaces...
I think, however, that such small utility classes like the commons
should really think twice before going happily into security-breaking
and should document their inability to run as an applet.
Thanks.
Paul
On Mardi, déce 17, 2002, at 19:39 Europe/Brussels, robert burrell
donkin wrote:
> i'm a bit confused by this. care to expand?
>
> - robert
>
> On Tuesday, December 17, 2002, at 11:05 AM, Paul Libbrecht wrote:
>
>> Possibly opposed to this requirement, I would insist that BeanUtils
>> may sometimes be used with Applets. Maybe a switch is useful, maybe
>> there is a fast method towards everything...
>>
>> Paul
>>
>>
>> On Mardi, déce 17, 2002, at 09:43 Europe/Brussels, Stephen Colebourne
>> wrote:
>>
>>> MethodUtils is currently being reworked in [lang]. Hopefully the new
>>> version
>>> there can include some level of caching.
>>>
>>> Stephen
>>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:commons-user-unsubscribe@jakarta.apache.
>> org>
>> For additional commands, e-mail:
>> <mailto:commons-user-help@jakarta.apache.
>> org>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
Re: [BeanUtils] MethodUtils caching
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i'm a bit confused by this. care to expand?
- robert
On Tuesday, December 17, 2002, at 11:05 AM, Paul Libbrecht wrote:
> Possibly opposed to this requirement, I would insist that BeanUtils may
> sometimes be used with Applets. Maybe a switch is useful, maybe there is
> a fast method towards everything...
>
> Paul
>
>
> On Mardi, déce 17, 2002, at 09:43 Europe/Brussels, Stephen Colebourne
> wrote:
>
>> MethodUtils is currently being reworked in [lang]. Hopefully the new
>> version
>> there can include some level of caching.
>>
>> Stephen
>>
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-user-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-user-help@jakarta.apache.
> org>
>
Re: [BeanUtils] MethodUtils caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Possibly opposed to this requirement, I would insist that BeanUtils may
sometimes be used with Applets. Maybe a switch is useful, maybe there
is a fast method towards everything...
Paul
On Mardi, déce 17, 2002, at 09:43 Europe/Brussels, Stephen Colebourne
wrote:
> MethodUtils is currently being reworked in [lang]. Hopefully the new
> version
> there can include some level of caching.
>
> Stephen
>
Re: [BeanUtils] MethodUtils caching
Posted by Stephen Colebourne <sc...@btopenworld.com>.
MethodUtils is currently being reworked in [lang]. Hopefully the new version
there can include some level of caching.
Stephen
----- Original Message -----
From: "Matt Smith" <ms...@dorado.com>
To: <co...@jakarta.apache.org>
Sent: Tuesday, December 17, 2002 8:03 AM
Subject: [BeanUtils] MethodUtils caching
I'm looking for a way to speed up some of my uses of Digester, and
SetNextRule heavily relies upon MethodUtils.invokeMethod. What I've seen is
that most of the time spent in getMatchingAccessibleMethod, and in
particular in Class.getMethods(). Most of this is wasted work, since it's
pretty much always the same class and paramType list being used for any
particular instance of SetNextRule. So I'd like to cache the results of
getMatchingAccessibleMethod, but it's private, making it a cut & paste job
to do so. I can do that if I have to, but I was wondering if there is any
code out there that is currently doing this type of caching already, of if
you guys can tell me a better way to deal with this. I'd like to continue to
benefit from updates to BeanUtils without re-copying code every time.
-Matt
Re: [BeanUtils] MethodUtils caching
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wednesday, December 18, 2002, at 12:44 AM, Matt Smith wrote:
> Robert -
>
> This statement confused me at first, because the first thing I tried was
> updating from BeanUtils1.3 to BeanUtils1.5. I did not find any difference
> in
> the performance characteristics. Both contain a call to Class.getMethods(
> ),
> which my profiler indicated was where most of the work was being done.
>
> However, I'm currently running under JDK1.3. I looked at the source for
> JDK1.4, and Class does indeed now cache a bunch of calls, including
> getMethods(). Updating to JDK1.4 had a significant impact on the
> performance
> characteristics for this particular call.
>
> As usually works out, however, doing no work at all is faster than doing
> some work. I found that my personal implementation of caching the result
> of
> of getAccessibleMethod() improved things further still. On the particular
> data set I'm running on, the normalized times were:
> JDK1.3: 1.0
> JDK 1.4: 0.85
> Cached: 0.66
>
> It's possible that for most people it doesn't make a difference, however.
> My
> data is "perversely leafy", which makes it call these digester rules many
> times.
that'd make sense. i used the tomcat web.xml when i did the profiling.
caching has some wrinkles (like classloaders) plus MethodUtils has been in
an unofficial code freeze. i'm very keen to work on caching but i think
that it must wait until after the next (bugfix) release. (hopefully that
will be very soon now.)
- robert
Re: [BeanUtils] MethodUtils caching
Posted by Matt Smith <ms...@dorado.com>.
Robert -
This statement confused me at first, because the first thing I tried was
updating from BeanUtils1.3 to BeanUtils1.5. I did not find any difference in
the performance characteristics. Both contain a call to Class.getMethods(),
which my profiler indicated was where most of the work was being done.
However, I'm currently running under JDK1.3. I looked at the source for
JDK1.4, and Class does indeed now cache a bunch of calls, including
getMethods(). Updating to JDK1.4 had a significant impact on the performance
characteristics for this particular call.
As usually works out, however, doing no work at all is faster than doing
some work. I found that my personal implementation of caching the result of
of getAccessibleMethod() improved things further still. On the particular
data set I'm running on, the normalized times were:
JDK1.3: 1.0
JDK 1.4: 0.85
Cached: 0.66
It's possible that for most people it doesn't make a difference, however. My
data is "perversely leafy", which makes it call these digester rules many
times.
-Matt
----- Original Message -----
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Tuesday, December 17, 2002 10:38 AM
Subject: Re: [BeanUtils] MethodUtils caching
are you using the latest beanutils release?
the performance of this code was significantly improved for the last
release.
- robert
On Tuesday, December 17, 2002, at 08:03 AM, Matt Smith wrote:
> I'm looking for a way to speed up some of my uses of Digester, and
> SetNextRule heavily relies upon MethodUtils.invokeMethod. What I've seen
> is that most of the time spent in getMatchingAccessibleMethod, and in
> particular in Class.getMethods(). Most of this is wasted work, since it's
> pretty much always the same class and paramType list being used for any
> particular instance of SetNextRule. So I'd like to cache the results of
> getMatchingAccessibleMethod, but it's private, making it a cut & paste
> job to do so. I can do that if I have to, but I was wondering if there is
> any code out there that is currently doing this type of caching already,
> of if you guys can tell me a better way to deal with this. I'd like to
> continue to benefit from updates to BeanUtils without re-copying code
> every time.
>
> -Matt
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: [BeanUtils] MethodUtils caching
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
are you using the latest beanutils release?
the performance of this code was significantly improved for the last
release.
- robert
On Tuesday, December 17, 2002, at 08:03 AM, Matt Smith wrote:
> I'm looking for a way to speed up some of my uses of Digester, and
> SetNextRule heavily relies upon MethodUtils.invokeMethod. What I've seen
> is that most of the time spent in getMatchingAccessibleMethod, and in
> particular in Class.getMethods(). Most of this is wasted work, since it's
> pretty much always the same class and paramType list being used for any
> particular instance of SetNextRule. So I'd like to cache the results of
> getMatchingAccessibleMethod, but it's private, making it a cut & paste
> job to do so. I can do that if I have to, but I was wondering if there is
> any code out there that is currently doing this type of caching already,
> of if you guys can tell me a better way to deal with this. I'd like to
> continue to benefit from updates to BeanUtils without re-copying code
> every time.
>
> -Matt