Re: Some observations

[Sean Allen <zeroone@worldonline.co.za>]

> > What about using a ClassLoader architecture for dynamic runtime
> > adaptition to whatever enviroment we are running in
> > i.e. If we are using JDK1.3 Classloader find's out using System.env and
> > dynamically loads whatever classes are nessicary to operate most
> > efficiantly in that enviroment.
> > This would allow for maximum compatibility but remove any compilie-tine
> > fiddling.

> Sounds like a good idea to me. The only problem is that one would have to 
be
> careful not to fall into the trap of being incompatible with future
> versions. If this is going to be based on the java.version variable, can 
one
> count on all JDK 1.3 VMs to signal their compatibilit correctly?

> Is it even specified anywhere that java.version must reflect the JDK API 
a
> VM implements?

Some brief research shows it is.
The Java Product Versionin Specification (November 30 1998 )
Says
An implementation of the Java Virtual Machine should be identify both the 
specification and the implementation. These properties should be added to 
those already available using java.lang.System.getProperties.
java.vm.specification.version
i.e. 1.3
java.vm.specification.vendor
i.e. Sun Microsystems Inc.
java.vm.specification.name
i.e. JavaTM Virtual Machine Specification
java.vm.version
i.e. Solaris 5.5 Native 1.0 build32
java.vm.vendor
i.e. Sun Microsystems Inc.
java.vm.name
i.e. Solaris 5.x JVM
Sorry for the HTML but it is 1 in the morning here and I have a big day 
tomorrow =-)
I would assume (I'll check when I have time) that this has been 
implemented in JDK 1.3 therefore i think that all JVM would have to 
implement (exept older ones) which for our purposes is moot, as a lack of 
Versioning information would result in classloader assuming it is 1.1 or 
1.2 JVM and NOT loading 1.3 (or 1.4 ;-) specific code.
I will give this a little more time tomorrow afternoon.
Sean Allen