This is the mail archive of the
mailing list for the Java project.
Re: security providers and ...
- From: Vladimir Puskas <vpuskas at eunet dot yu>
- To: tromey at redhat dot com
- Cc: java at gcc dot gnu dot org
- Date: Tue, 9 Jul 2002 15:45:39 +0200
- Subject: Re: security providers and ...
- References: <02042318321700.06739@mcphails> <email@example.com>
Sorry, I've left without an answer. Usually I don't act this way. Job took my
attention elsewhere, but now I'm back.
On Monday 06 May 2002 23:45, Tom Tromey wrote:
> >>>>> "Vladimir" == Vladimir Puskas <vpuskas@EUnet.yu> writes:
> I didn't see a response to this.
> Vladimir> 1) The 'gnu.java.security.provider.Gnu' says that it
> Vladimir> supports MD5 beside other things but
> Vladimir> 'gnu.java.security.provider.MD5' simply isn't there.
> That must be an oversight or missed merge opportunity. Sorry about
I get my GCC/GCJ by downloading weekly snapshot and building it.
As far as I know, classes I have mentioned, aren't there. To remedy this I'll
send them to the list, or whereever you advise me. Last time I haven't
offered this because they are part of GNU Classpath project, and I expected
someone would merge them.
> Vladimir> Question is:
> Vladimir> Can I at runtime, know where class is loaded from? Has it
> Vladimir> been in shared library or class/jar file?
> As far as I know there isn't a way to do this from Java.
> You could probably do it in C++ by digging around in internal data
> structures. I doubt there is an "approved" way to do this, but if we
> knew what you needed to do maybe we could make one.
My idea was to intercept Enhydra's classloader and prevent it loading a class,
if class is already compiled and linked into binary. Classloader supports
filtering which would perfectly match this task, but I couldn't find the
method to do this.
Anyway, this feature (intended to be optimization step) has fell down on my
task list, since new Enhydra 5.0 (Aonyx) is released.