coolness

[Godmar Back]

> 
> 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