On Jul 20, 2007, at 4:17 PM, Paul Cunningham wrote:
I expect that this approach terrifies a lot of people. A lot of
developers get upset about "too many moving parts". But this is the
nature of dynamic applications and this kind of thing happens to
you all the time in the Real World. I say go with the flow and
embrace programming techniques that support this style of programming.
I'm afraid we're in danger of taking this UML thread off-topic to
java. But, if you want dynamic you can get about as dynamic as you
want with java ClassLoader's and reflection.
Now this no longer works at 1.6 but you used to even be able to
'test' dynamic instances of 'java.' package classes. My main one was
to substitute for most of the main java.io classes to allow zip files
to be accessed transparently using file methods as if they were
normal directories.
For example the File.exists() method...
public boolean exists() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(path);
}
if (ffsFile != null) // mjh
if (ffsFile.isHandledMethod("exists()"))
return ffsFile.exists();
The java.io.File class is replaced by a proxy that delegates it's
actions to either a normal, or primordial file instance if the file
is not zip or to a class that implements the same methods for zip
files. So you might have a zip file path like classes.jar/
com.foo.MyClass. The zip handling class would split this path into
the correct zip file and zip entry. That would be the ffsFile
instance above, if the constructor decided to create a zip file
instance and that instance indicates that the exists() method or
message if you prefer the terminology is supported by that instance
then it handles it. (ffs indicates foreign file system, an old
classical Mac OS thing, I just liked the name, but the idea is not
just zip but any type of substitute file system could be
instantiated),Otherwise if no primordial 'normal' java.io.File
instance was obtained it just returns false rather than throw an
exception. If a primordial instance has been obtained and there was
no ffs instance or the ffs instance declined to handle the method for
this instance, then you get whatever the primordial instance returns.
That reflection invoked of course because thats the only way to work
with a same named instance of a class from another ClassLoader in the
current ClassLoader.
So at runtime the class that handles the method can be whatever one
you decide to pass it to. That class can decide whether or not it
wants to handle the method/message for that instance. If it doesn't
you can pass it to another class or you can default handle it. How
much more dynamic do you want?
At 1.6 you can no longer use a custom ClassLoader on anything from
the java. package. It probably violated something related to the Sun
licenses doing so earlier, but it worked, for testing purposes only,
of course.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
