Closed Bug 354817 Opened 18 years ago Closed 2 years ago

JavaXPCOM fails to initialize if XULRunner path contains native characters

Categories

(Core Graveyard :: Java to XPCOM Bridge, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: vkorenev, Unassigned)

Details

Attachments

(1 file)

2.25 KB, patch
vkorenev
: review?
jhpedemonte
vkorenev
: review+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060919 Firefox/1.5.0.7
Build Identifier: 

If XULRunner is installed to path containing non-latin alphabet characters, Mozilla.initEmbedding() call fails with an exception:

Exception in thread "main" java.lang.RuntimeException: java.io.FileNotFoundException: cannot access GRE_HOME
	at com.jniwrapper.xpcom.tests.InitTest.main(InitTest.java:32)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.io.FileNotFoundException: cannot access GRE_HOME
	at org.mozilla.xpcom.Mozilla.getGREPathWithProperties(Mozilla.java:105)
	at com.jniwrapper.xpcom.tests.InitTest.main(InitTest.java:20)
	... 5 more

Reproducible: Always
Attached patch PatchSplinter Review
Attachment #240605 - Flags: review+
Attachment #240605 - Flags: review?(jhpedemonte)
I can't recreate this.  What non-Latin characters where in the path name?  What is the LANG env var set to?

The docs for |getBytes()| say, "The behavior of this method when this string cannot be encoded in the default charset is unspecified.", which worries me.  I'm guessing that this undefined behavior won't be hit often...
I encountered this problem in XPCOM 1.9.0.11 on Windows XP.
OS's codepage is cp-1251.

XPCOMGlueLoad accepts XPCOM shared library pathname in native 8-bit encoding. So, non-ascii chars must are encoded in cp-1251. But LoadXULMethods in nsJavaXPCOMGlue.cpp conerts jstring path to UTF-8.

I guess patch in #1 resolves the issue.
Assignee: jhpedemonte → nobody
Product: Core → Core Graveyard

JavaXPCOM was removed in bug 648593.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: