Lists Home |
Date Index |
- From: "Mark L. Fussell" <email@example.com>
- To: Tim Bray <firstname.lastname@example.org>
- Date: Sun, 14 Dec 1997 18:38:50 -0800 (PST)
On Sun, 14 Dec 1997, Tim Bray wrote:
> I'd like for people who want to use Lark as just a WF checker to
> avoid the overhead of downloading 60K of validation rubbish. Lark now
> has a method called lark.validate(boolean) and if it's not turned on,
> none of those textuality.validator classes will ever get invoked.
> However, is an applet loader going to pull 'em all in over the
> network regardless?
For most VMs, if the code executed encounters the class as a variable type
it will ask the ClassLoader to load it. If you want to prevent a class
from loading you need to prevent any references to the class from occuring
except in the exact context when you want it to be loaded.
> Or, should I provide stubbed-out class files for the only two classes
> that are directly referenced, DTD and Validator?
> Or, is this worth worrying about? Or is there a standard way to
> achieve this effect? Wisdom welcome. -Tim
The simplest approach would be to define an interface or abstract class
for the DTD and validator that has the minimum your main class needs.
This will always be loaded with the main class. Then you can
implement/subclass off this interface to put the full validation
functionality in. Finally, have exactly one method in the main class that
constructs an object of the full implementation (assigning it to a
variable of the general type) and only call this method when you need to.
The full implementation classes should only be loaded when this
particular method is called, so (for your example) only when validation
is turned on.
You can verify what is happening with loading by turning on 'java' verbose
mode to see if everything is working ok. Some VMs behave differently
(delayed loading is not part of the Java spec, just common), but I think
most VMs behave this way.
Hope that helps.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)