Closed Bug 391642 Opened 17 years ago Closed 15 years ago

Try-catch sometimes does not catch Java LiveConnect exceptions but instead fails

Categories

(Core Graveyard :: Java: Live Connect, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: brettz9, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

In the global scope (so as to allow the menu command to be repeated without having a problem with already loaded DLL's):

var fURL = new Array();
fURL[0] = new java.net.URL("file:///C:/Berkeley DB XML/jar/dbxml.jar");
fURL[1] = new java.net.URL("file:///C:/Berkeley DB XML/jar/db.jar");
loader = new java.net.URLClassLoader(fURL);

Within an onMenuItemCommand function:

var xmlmanconfigClass = loader.loadClass("com.sleepycat.dbxml.XmlManagerConfig");
var xmlmanconfig = xmlmanconfigClass.newInstance();
xmlmanconfig.setAllowExternalAccess(true);
var xmlmanClass = loader.loadClass("com.sleepycat.dbxml.XmlManager");
var reflect = java.lang.reflect;
var paramtypes = reflect.Array.newInstance(java.lang.Class, 1);
paramtypes[0] = xmlmanconfigClass;
var constructor = xmlmanClass.getConstructor(paramtypes);
var arglist = reflect.Array.newInstance(java.lang.Object, 1);
arglist[0] = xmlmanconfig;
var xmlman = constructor.newInstance(arglist);
var myContainer = xmlman.openContainer("myContainer1.dbxml");
var uContext = xmlman.createUpdateContext();

try {
	myContainer.putDocument("tempfile", "<people><person><name>Joan</name></person><person age='65'><name>Steve</name></person></people>", uContext);
}
catch (e) {
	alert("Got through catch.");
}

The specific Java Console errors are:

Caused by:
com.sleepycat.dbxml.XmlException: Error: Document exists: tempfile, errcode = UNIQUE_ERROR
at com.sleepycat.dbxml.dbxml_javaJNI.XmlContainer_putDocument__SWIG_3(Native Method)
at com.sleepycat.dbxml.XmlContainer.putDocument(XmlContainer.java:377)

I am actually expecting the errors in this case, but I want the catch to be set up to ignore the errors (especially since the BDBXML API has no document-exists detection)....

It seems someone else also reported a problem which included a LiveConnect try-catch failure too, though that bug was not directly related: https://bugzilla.mozilla.org/show_bug.cgi?id=376065


Reproducible: Always

Steps to Reproduce:
1. Install BDBXML (for Windows at least, I haven't tested other installations)
2. Put the BDBXML DLL's (in the /bin directory) into the C:\Program Files\Mozilla Firefox directory (I don't know if there is any other way to do this). 
3. Add a .java.policy file to one's home directory (in my case alerting java.lang.System.getProperty("user.home") indicating C:\Documents and Settings\Brett Zamir , granting permissions such as the following...
e.g.,
grant codeBase "file:///C:/Berkeley DB XML/jar/dbxml.jar" {
   permission java.security.AllPermission;
};
grant codeBase "file:///C:/Berkeley DB XML/jar/db.jar" {
   permission java.security.AllPermission;
};
(I also don't know if there is some other way to do this, besides with an XPCOM component.)
4. Try the code cited in the description in a XUL extension.

Actual Results:  
The Java Console reports errors and the script fails

Expected Results:  
The catch block should be activated with information on the Java exceptions thrown without the script failing.
The above script should also have the following at its end:

uContext.delete();
myContainer.delete();
xmlman.delete();
Component: General → Java: Live Connect
Product: Firefox → Core
QA Contact: general → live-connect
I've since looked around further and found the following bugs which seemed similar to this one: 47272, 366778, 383302 ... It seems 1/10 of the bugs for LiveConnect are related to this then... What's the deal?
This problem still occurs in FF3.0b2... Even the simple example from the MDC docs at http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:LiveConnect_Overview:JavaScript_to_Java_Communication#Handling_Java_Exceptions_in_JavaScript
will fail:

try {
    var theClass = java.lang.Class.forName("ThisIsNotARealClass");
} catch (e) {
    alert ("The Java exception is " + e);
}

will cause errors in the Java console causing any future attempts to use Java in the script to fail.
By the way, my purpose for doing this is to give extensions access to both XQuery and XSLT 2.0 (via Saxonica). I've already got a working extension at https://addons.mozilla.org/en-US/firefox/addon/5515 but this depends on a wrapper class to catch all exceptions and I don't want to have to write wrapper classes for thousands of methods (and in the process also necessarily come up with an imperfect solution for returning the exceptions back to Javascript)!

If this one bug can be fixed, extension developers can have easy easy to XQuery and XSLT 2.0 (as well as Saxon's XPath processor) and optionally via native XML databases. A developer working on the XForms implementation as well as XML database developers have expressed interest to see this work, and this bug is the only real barrier to this...

Anything I can do?
Some folk(s) have done a whole lot of work to make LiveConnect work. This is an incredible achievement, and while I can appreciate it may be hard to fix this bug (as one developer indicated in IRC), I think it is a crying shame to let this great power of being able to directly use a language for which there are so many powerful libraries (i.e., Java), go to waste, especially since this is the only bug I've noticed in working with LiveConnect.

With this bug, one has to write wrapper functions which catch the errors within Java, not only for each class that is invoked, but also for the potential return objects (since those might throw an exception when invoked too). And one must ensure that the same object (or string) is being returned since one needs the returned error to be of the same type as the potentially returned object/string. LiveConnect is elegant, but with this ONE bug, it is all extremely inefficient to work with.

Anyone willing to fix it for some cash?
(In reply to comment #5)
> Anyone willing to fix it for some cash?

Is this offer still available, and how much are you talking?  (I'm not able to do so, but it would be easier for me to mention it to people who might be if there were definitive numbers.)
About how much do you think it would take (given, from what I hear, is some very complex LiveConnect code) to make developers in the know to say, "Sure, that'd be worth it."? I'm guessing I couldn't afford it all myself, but I think it's possible I could find others to chip in toward it.
(In reply to comment #7)
> About how much do you think it would take (given, from what I hear, is some
> very complex LiveConnect code) to make developers in the know to say, "Sure,
> that'd be worth it."? I'm guessing I couldn't afford it all myself, but I think
> it's possible I could find others to chip in toward it.
> 

I have no idea, I was just trying to see how much you were offering.  It is very rare, but I could easily see a company being inconvenienced by a bug so much that they would be willing to pay for someone (most likely not a Mozilla Corporation employee) to devote time to a fix.
This bug has at long last now been resolved as of Java 6 update 12, with the move to the new implementation of LiveConnect. See https://jdk6.dev.java.net/plugin2/#LIVECONNECT , https://jdk6.dev.java.net/plugin2/liveconnect/ , http://forums.java.net/jive/thread.jspa?threadID=45933&tstart=0
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
marking WFM, see bug 434658 comment 8 for reasoning
Resolution: FIXED → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.