xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McCormack <...@mcc.id.au>
Subject Re: FW: Strange applet delay revisited
Date Fri, 30 Jan 2009 05:22:07 GMT
Hi Helder.

Cameron McCormack:
> > Currently, the following packages are imported

Helder Magalhães:
> Wow, impressive! :-) Does this mean that to achieve a standard
> ECMAScript binding this would be the class list? I can try to marsh up
> a patch from this if it sounds useful...

That’s correct, though if we don’t eliminate the importPackage() for
java.lang then there’s no point importing these org.w3c classes
explicitly, since the class loader will still go out to the network,
AFAICT.

Once we’ve decided on the best course of action, I’d be happy to land a
patch that fixes the problem.

> Humm... I'm not sure about this, but this sort of things would be
> tied to a particular implementation (Batik, in this case), so I'd
> argue that, for this sort of functionality, explicit "importPackage"
> calls could become a requirement - this way, it would be obvious that
> an implementation-specific feature (and not a standard ECMAScript
> binding) was being used, potentially avoiding interoperability
> issues that could raise from not knowing that... Would this behavior
> make sense or am I missing something (such as breaking current
> functionality or similar)?

I agree.  Were I starting from scratch, I’d expose only
importPackage, importClass and Packages from Rhino (as well as the
classes from org.w3c).  At the moment, there are standalone SVG files in
samples/ that rely on java.lang being imported.  I suspect that there
are many users of Batik who create/use documents with such a dependency,
too.

At least if we did

  java = Packages.java

then the global scope won’t be polluted with additional classes each
time you upgrade to a newer JRE version.

So perhaps the best solution is to make RhinoInterpreter (or maybe
Interpreters in general, via InterpreterPool?) configurable as to
whether it should import java.lang classes automatically.  A JSVGCanvas
would import by default, for compatibility with those writing their own
applications using Batik.  There’s an argument to making Squiggle
configure its JSVGCanvas not to import the whole java.lang package, to
avoid incompatibilities with scripts that would work in other UAs, but
I’d be happy either way there.  Those who want to embed a JSVGCanvas in
an applet can configure it not to import java.lang.

Thoughts?

-- 
Cameron McCormack ≝ http://mcc.id.au/

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message