Issue 95162 - Java extensions cannot be installed in some environments
Summary: Java extensions cannot be installed in some environments
Status: CLOSED DUPLICATE of issue 93769
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0
Hardware: All Windows, all
: P2 Trivial with 4 votes (vote)
Target Milestone: OOo 3.1
Assignee: Stephan Bergmann
QA Contact: issues@framework
Depends on:
Reported: 2008-10-19 19:47 UTC by milek_pl
Modified: 2008-11-13 09:05 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Exception thrown when installing to userdir with non-ascii characters (469.71 KB, image/png)
2008-10-29 13:25 UTC, joerg.skottke
no flags Details
Found it. (127.14 KB, image/png)
2008-10-30 10:34 UTC, joerg.skottke
no flags Details
partial fix (5.36 KB, patch)
2008-10-31 17:30 UTC, Stephan Bergmann
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description milek_pl 2008-10-19 19:47:11 UTC
In some Java installs (notably in Windows XP SP3), Java UNO services cannot be

The message is unhelpful (the issue 75316 might make it more intelligible):

{{Message="", @0}}

It affects all Java extensions on such machines. See for example reports at:

Some people reported that disabling all Java versions older than 6 might help
but in tests, it turned out to be false. Java works on affected machines but OOo
cannot register any Java services.

Note: it's hard to replicate but I have at least ten reports from different
people trying to install LanguageTool in OOo 3.0 about this, so please don't
close it with WORKSFORME. It also works for me - there just must be some special
conditions that trigger the bug.
Comment 1 joachim.lingner 2008-10-22 15:01:52 UTC
@jsk: Could you try to reproduce this?
Comment 2 milek_pl 2008-10-22 16:58:40 UTC
FYI, the link to other reports about it with LT 0.9.4 is here:
Comment 3 milek_pl 2008-10-27 22:18:34 UTC
Found the reason: the bug appears when the username contains non-ASCII
characters (such as Russian or Polish characters). The admin-mode install works
fine in such cases (most of the time), as admin accounts usually have shorter
names without such chars.

Raising the priority as now it's fixable and severe: you cannot use any
user-mode installed Java extension in certain user accounts.
Comment 4 auberon 2008-10-28 06:39:13 UTC
I am the one who reported the bug:

Milek is right.

My username contains a non-ASCII character.
But when I logged as Administrator (Windows), I can install the Java extension
Comment 5 joerg.skottke 2008-10-29 13:21:30 UTC
Confirmed, but i fail with a,
stating that i'm working on a read-only context.

Making this a stopper for 3.0.1
Comment 6 joerg.skottke 2008-10-29 13:25:54 UTC
Created attachment 57543 [details]
Exception thrown when installing to userdir with non-ascii characters
Comment 7 joerg.skottke 2008-10-29 13:27:02 UTC
Not yet confirmed for Unixish platforms, so i'm setting OS to Windows/all for now.
Comment 8 milek_pl 2008-10-29 17:26:50 UTC
milek->jsk: According to a report on the extension website, this happened
already in 2.3.1 on OpenSuse, so this might affect Unixish platforms as well
(though I'm not sure if all of them allow non-ASCII usernames):

I will try to create such an account on my Suse box today and test it.
Comment 9 milek_pl 2008-10-29 18:16:51 UTC
It turns out that by default Linux systems disallow non-ASCII characters in user
names. For example, KDE by default doesn't understand non-ASCII usernames.
Comment 10 joerg.skottke 2008-10-30 10:07:05 UTC
Hi Milek,

while trying to reproduce this issue i ran into another problem which i now
filed as issue 95628.
I discussed this problem with HRO, one of our core system geeks and he pointed
out that your issue is most likely not related to characters being outside the
ASCII table (which made me fail in reproducing this issue) but that the
characters are outside the *ANSI* Table - which makes a slight difference that i
was not aware of.

However, until now i've been unable to reproduce the problem. I always run into
issue 95628 before even getting to the exception you reported.

Could you please provide me with following information so i can build a 1:1
- Which locale was the office installed under (en_US?)
- Which locale does is your user have (pl_PL?)
Or do you use UTF-8 locales?
Comment 11 joerg.skottke 2008-10-30 10:33:47 UTC

I got it, apparently my name is good enough for an exception as well - the
simplest solution is always the best.

@JL: Reproduction is simple
- Install office as local administrator for all users
- Create a local user named "Jörg"
- Switch to the new user
- Start the office
- Install LanguageTool 
-> Exception

Note that apparently not all extensions are affected, really use the Language
Tool (0.9.4).
So this issue appears for a very common use case so priority and target remain ok.
You cannot use Linux for reproduction as you are not allowed to create a user
with such a name.
Comment 12 joerg.skottke 2008-10-30 10:34:43 UTC
Created attachment 57569 [details]
Found it.
Comment 13 milek_pl 2008-10-30 12:10:58 UTC

- Which locale was the office installed under (en_US?)

pl_PL (but we had reports from fr_FR as well)

- Which locale does is your user have (pl_PL?)

pl_PL - but in Windows, we have two different codepages, cp852 (IBM Latin2),
which is OEM, and CP1250, which is normally called ANSI in most programs but is
actually not ANSI at all. Don't ask me who could have created such a conceptual

Now, I have a special account on my box called "Wiesław Żółć" created normally
in Windows - and this account is used for replicating this bug.

Probably TCM sanity tests should mention running on "Wiesław
Żółć" account.

BTW, all and only Java extensions are affected.
Comment 14 auberon 2008-10-30 16:04:06 UTC
The problem occurs not only at installation.

I desactivated LanguageTool with my non-ASCII username. -> OK.

If I try to reactivate it, I get also the following message:
{{Message="", @0}}
Comment 15 auberon 2008-10-30 16:20:09 UTC
I don't know if there is a relation, but for the first time, after this test,
OOo refused to quit. The red-right-top button or the menu command performed no
I had to kill the processes.
Comment 16 joachim.lingner 2008-10-31 15:42:13 UTC
An easier way to reproduce is to create a local folder, for example:


and then edit the bootstrap.ini:

The actual problen is in jurt, method 

If the class is to be loaded with an URLClassLoader then this fails, because of
the location URL which uses UTF8, but Java expects something different here.
Comment 17 Stephan Bergmann 2008-10-31 17:30:09 UTC
Created attachment 57621 [details]
partial fix
Comment 18 Stephan Bergmann 2008-10-31 17:39:45 UTC
[Testing with LanguageTool-0.9.4.oxt from

The attached jurt.patch adds the missing call to  However, with this partial fix, extension
installation still fails due to jar.openStream() at
ridljar/source/unoloader/com/sun/star/lib/unoloader/ l. 193
now throwing a java.lang.IllegalArgumentException (even though the
jar.toString() =
looks good).  This needs further evaluation.

I assume the error is present since the class path cleanup in OOo 2.3.  I have
no time to fix this for OOo 3.0.1, hence move it to OOo 3.1.
Comment 19 milek_pl 2008-10-31 18:04:39 UTC
milek->sb: this is a known Java bug, see

Try this (this is a recommended workaround):

JarInputStream s = new JarInputStream(new URI(jar).toASCIIString().openStream());

Comment 20 milek_pl 2008-11-03 20:34:08 UTC
milek->sb: I managed to fix one half of the remaining bug. It's enough to add
the following to getJarMainAttributes(URL jar):

JarInputStream s = new JarInputStream(new URL(		
URLDecoder.decode(jar.toString(), System.getProperty("sun.jnu.encoding",

But immediately after it I get IllegalArgumentException with 

cl2.loadClass(name) in RegistrationClassFinder.

I instrumented the exception and here's the stack:

java.lang.IllegalArgumentException Source)
sun.misc.URLClassPath$JarLoader.<init>(Unknown Source)
sun.misc.URLClassPath$ Source) Method)
sun.misc.URLClassPath.getLoader(Unknown Source)
sun.misc.URLClassPath.getLoader(Unknown Source)
sun.misc.URLClassPath.getResource(Unknown Source)$ Source) Method) Source)
java.lang.ClassLoader.loadClass(Unknown Source)
java.lang.ClassLoader.loadClass(Unknown Source) Source)
java.lang.ClassLoader.loadClass(Unknown Source)

I tried decoding the URL the same way as above for class loader constructor but
it didn't work (the version with UTF-8 as-is, UTF-8 percent-encoded and UTF-16
failed). If anyone has an idea what is the proper representation of the URL for
loadClass (that is, for UnoClassLoader, which is in turn only using the
inherited method from URLFactoryClassLoader, as far as I remember), I'd
appreciate it. Note that there is some strange problem here: the string produced
by explicitly calling on url.toString() is the same
as url.toString() and there is no error in that case. So the problem is probably
not just with ParseUtil.decode(). Any pointers, anyone?
Comment 21 milek_pl 2008-11-05 01:24:08 UTC
I found out the reason why the second IllegalArgumentException appears. The
first fix (with URLDecoder) works fine for all extensions that contain jar files
that don't have anything on the classpath (like A Letras from the Extensions
website). In case there is some non-empty classpath, ParseUtil.decode() gets
crazy. I tried a very brutal fix (removing classpath from attr in
RegistrationClassFinder) but it didn't help at all with registering a class.
Comment 22 joerg.skottke 2008-11-11 11:52:51 UTC
cc HRO
Comment 23 Stephan Bergmann 2008-11-13 08:40:31 UTC
My attached jurt.patch of course is nonsense.  It appears I had completely
forgotten about issue 93769.

*** This issue has been marked as a duplicate of 93769 ***
Comment 24 Stephan Bergmann 2008-11-13 09:05:42 UTC