coolness

Fri Mar 12 09:20:00 GMT 1999

>> Tom Tromey wrote:
> > 
> > >>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:
> > 
> > Jeff> What needs to work in gcj is Class.forName("...") which is
> > Jeff> scattered all over in most java code, including the Sun java.*
> > Jeff> classes, and most JDBC programs (consider how JDBC drivers are
> > Jeff> loaded dynamically).
> > 
> > When you write this, do you mean that it is a common idiom to pass a
> > constant string to Class.forName()? (I'm afraid most of the Java code
> > I've read is code written here.)
>> Yes. Sometimes it is useful to get a reference to some class before any
> instances are created:
>> try {
> Class objClass = Class.forName("java.lang.Object");
> } catch (ClassNotFoundException ex) {
> ...
> }
>
>From my experience, a much more common use of Class.forName is with
non-constant strings that are composed at runtime. 
For instance, it may be used like so:
	Class beaninfo = Class.forName(beanpackage + classname + "Info");
where beanpackage may be "kaffe.bean.info.", and classname is a variable.
> In 1.1 javac introduced a new syntax:
>> Class objClass = java.lang.Object.class;
>> but javac still generates a call to Class.forName(...) in the bytecode. 
> The new syntax is just a compiler trick, not a VM feature.
>
However, if egcs compiled from a .java source, these guys would be 
absolutely no problem: egcs is not obliged to create Class.forName(...) calls
like javac does --- at least not as long as ClassLoaders are kept out of 
the picture.
	- Godmar