This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: RFC: PR 9125
- From: Tom Tromey <tromey at redhat dot com>
- To: Anthony Green <green at redhat dot com>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>
- Date: 22 Jan 2003 15:32:35 -0700
- Subject: Re: Patch: RFC: PR 9125
- References: <87vg0ip140.fsf@fleche.redhat.com><1043190334.1466.29.camel@escape>
- Reply-to: tromey at redhat dot com
>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:
Anthony> This might cause problems for application servers where
Anthony> you're tweaking jsp code and building .so files on the fly.
That was my concern as well, but I didn't know whether this scenario
showed up in the wild. Does it? Would an application server call,
say, Class.forName, have it fail, and then later call it and expect it
to succeed?
I suppose it is possible if the admin is installing a new .so in
response to, say, a "couldn't find class foo" note in the web server's
log file.
Anthony> Would it be OK to add a system property to enable/disable
Anthony> this behaviour?
I wouldn't mind, though I'd prefer to find some other solution.
This seems too much like adding a "make libgcj work" switch.
One idea would be to just leave things as they are.
(By default this is what we'll do for the release, since things aren't
any worse now than they were before.)
Another idea would be to somehow augment the cache to check for
directories changing. This may be expensive too though, not to
mention hard to implement (is there a way to find the list of
directories that dlopen searches?).
Tom