This is the mail archive of the
java@gcc.gnu.org
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> <87adrd6jds.fsf@creche.redhat.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
> that.
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.
Regards,
Vladimir Puskas