class linkage

Sat Aug 2 22:53:00 GMT 2003

On Sunday, Aug 3, 2003, at 05:14 Pacific/Auckland, rezaei@promail.com 
wrote:
> Bryce McKinlay wrote:
>>> void loadFakeDriver()
>> {
>> dynamically_create_bytecode_for_FakeDriver_and_put_it_into_the_classpa 
>> th ();
>> FakeDriver.run();
>> }
>> The concept in the above code is vital to any program that requires 
> run time
> compilation. Important examples include JSP servers and language
> interpreters. However, there are two ways of achieving the same result:
> 1) Using a custom class loader. This is the approach taken most often 
> today.
> Writing class loaders can be hell though.
> 2) Simply sticking a .class in the classpath and letting the default 
> class
> loader deal with it.
>>> But this code will have unspecified results according to the JLS, it 
>> isn't valid java source without a FakeDriver.class present, and it 
>> could be
>> made to work perfectly well using Class.forName().
>> Which approach violates the JLS? Which approach would work with gcj?

There is no problem with 1. There is no problem with 2, provided the 
application uses the proper methods for dynamic loading - eg 
Class.forName() etc.
It is only fixed symbolic references to classes that do not exist 
during class resolution/linking that would cause problems here, and the 
JLS makes it clear that linkage may occur before the point in your 
program where that reference is first used. Note that this type of 
program cannot be compiled at all with GCJ using the current ABI.
Regards,
Bryce.