• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OT: Categories and alloc.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OT: Categories and alloc.


  • Subject: Re: OT: Categories and alloc.
  • From: John Haager <email@hidden>
  • Date: Fri, 28 Jun 2002 17:14:16 -0700

On Friday, June 28, 2002, at 01:20 PM, Michael Gersten wrote:

[ snip ]
For you java experts, how does the class loader system work internally? I know that Java has one default loader that knows how to get classes from the JAR's in the classpath. I know that you can add loaders that know how to get classes from a database store, a web server, or any other location; they can choose to relax security to some extent, or check it tighter, etc.

But how does this all get started?

If I ask java for a class by name, has the initial class loader done a pre-scan of every JAR in the classpath to see if that class is there?

The Runtime creates a single Class Loader instance which is used to load classes. This Class Loader knows how to read JAR/ZIP files in the classpath as well as find individual class files in the class path.

When you intstantiate a class by name, the Class Loader first checks its cache to see if the class has already been loaded. If not, it searches the classpath for an implementation of that class. If one is found, it is loaded, and a corresponding Class object is returned. If it is not found, an exception is thrown.

Has it done a prescan to find all the additional class loaders, so that they can be loaded into memory and queried? Or do I have to explicitly load all the class loaders that I know of (which begs the question, how does a new class really get into the system if there isn't even a loader called that can add the class into the system?)

Java normally only deals with the default class loader. If you want to use some other Class Loader, you must instantiate it, and specifically use it to load the class you want. It will then use its method of finding classes (DB access, net download, etc) to look for the class you requested.

One important thing to know is that Foo.class loaded by the default Class Loader, and Foo.class loaded by MyCustomClassLoader are seperate and distinct and can both exist in a program at the same time.

[ snip ]

Keep in mind that adding new classes/packages can be done by the end user, with no access/ability to change the source or main executable. That means it ultimately has to be able to scan a CLASSPATH, or a PACKAGEPATH, or a FRAMEWORKS_PATH, or something like that.

I'm looking for ideas. I haven't even begun looking at the security issues (what if a package on the system doesn't really do what it claims, or does do what it claims, but also copies the data for someone else [no big brother concerns here, nope, nada]).

If you are going to do something of that nature, you'll probably have to implement your own custom Class Loader which knows where to look for classes. Custom Class Loaders are not all that difficult to implement, but there are a few gotchas that can bite you.

Michael

-> John Haager <-
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >OT: Categories and alloc. (From: Michael Gersten <email@hidden>)

  • Prev by Date: NSBezierPath fillRect - not honoring clipping?
  • Next by Date: UN-caching outline autosaved items
  • Previous by thread: OT: Categories and alloc.
  • Next by thread: Re: OT: Categories and alloc.
  • Index(es):
    • Date
    • Thread