Is the system class loader different than java.lang.ClassLoader (which is where I'm attempting the injection)? Sorry, I'm not as well versed with ClassLoaders as I should be. How does java determine name space? If I don't "inject" into URL, it can call java.net.URLStreamHandler.parseURL(Ljava/net/URL;Ljava/lang/String;II). If I inject a simple println statement in the constructor, it can't. Does that mean that since I injected into the code, another class loader (not the System class loader) loaded the class and therefore it can't access the protected method in URLStreamHandler? So if different class loaders load the classes, even if they have the same package name, they are considered different name spaces? How does java determine namespace?
Hmmmm.... ok, here's another question. Inside of java.lang.ClassLoader, when someone asks for a class, it asks the parent class loader to load the class, and then, java.lang.ClassLoader returns the class. Where is this class stored when it is "loaded into memory" Once again, sorry for the stupid questions. I'm just trying to get a handle on how the class loader works in java. And why do you hope there is no way to inject code into core java classes at runtime? Besides the huge potential for messing up core java classes? Thanks, --Abel ----- Original Message ----- From: "Peter Schneider" <[EMAIL PROTECTED]> To: "'BCEL Users List'" <[EMAIL PROTECTED]> Sent: Monday, August 12, 2002 10:15 AM Subject: RE: injecting code into java.* classes > I suppose wrong classloader! > The class your code wants to access was loaded by the system > classloader. > Which means it isn't in the same namespace and therefore it isn't > allowed to access these members. > > Btw, I really hope there is no way to inject such code, during runtime. > > Peter > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
