Java question

[Don Park]

Tim,

JStud here :-).  Since my cape is at the dryer, I will be your average Java
guru and see if I can answer your questions.  I must warn you that my ego is
positively radioactive <g>.

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

Rules on that issue is very hairy depending on which browser and which
version is used.  The Netscape browser, for instance, will download
referenced classes if there is no method involved.

a = b where b is an instance of class B.
a instanceof B

will cause code verifier to download class B.  However, a = b.foo(); will
not.  Their recommendation is that code like above should be wrapped inside
a method like this:

public class B {
    B foo () { return this; }
    boolean bar(Object a) { return a instanceof B; )
}

Frankly, I find all this details troublesome and not worth two tablets of
Advil.  I recommend staying well clear of it.

>I suppose if this is the case, I could create two different Lark
>distributions, using the trick documented in the O'Reilly book
>where I say
>
>private static final boolean sVALIDATE = false;
>
>and then bracket all refs to validation classes with
>
>if (sVALIDATE)
>{
>
>}
>
>which won't get compiled.

Above trick causes too much code management problem and is typically used
for debugging purposes only.  I wouldn't recommend it either.

>Or, should I provide stubbed-out class files for the only two classes
>that are directly referenced, DTD and Validator?

There is no need for stubbing.  You can create an interface for the
Validator and combine that with
Class.forName().  For example:

public interface XmlValidator {
    void doThis(XmlParser ctx);
    void doThat(XmlParser ctx);
}

public class XmlParser {
    public void validate () {
        ...
        XmlValidator validator =
            (XmlValidator)Class.forName("lark.SuperXmlValidator");
        validator.doThis(this);
        validator.doThat(this);
    }
}

You will need to wrap Class.forName code with some exception catchers but
above code basically allows late-binding to the SuperXmlValidator class and
only when it is actually used.  You will still need to have the
lark.SuperXmlValidator code in the same Zip or Jar file since not all
browsers support multiple Zip/Jar.  The trick of using invisible applets to
load multiple archives does not work either because the browser will use
different classloader if Zip/Jar specification attribute is different.
Anyway, interface + Class.forName scheme is better for code management since
you will only have to change the make file rather than Java source files.

>Or, is this worth worrying about?  Or is there a standard way to
>achieve this effect?  Wisdom welcome. -Tim


I think it is worth worrying about but there is no standard way.  I am
afraid that the browser war left the applet world still pretty much in the
wild and wacky west state.

Hope this helps,

Don "JStud" Park



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)