java-gnome-hackers

[java-gnome-hackers] Bug in loadNativeCode with non-ascii characters in path

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After I moved my local java-gnome Bazaar repository under a directory
with Turkish characters, I was unable to run it in place because of
escaped url usage for file operations. I was able to fix the issue by
unescaping the string and pushed the branch to
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/bug-load-native/

Please test and consider its merge to mainline before 4.0.10 we soon
plan to release.

Thanks in advance,

Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl8WJAACgkQRh6X64ivZaJSJACfYjFV3GJlTCvu0GvDYH5r9OUa
okUAnipjJTLRT19TKaoPcgtc4Ypp7pH0
=QRHw
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Bug in loadNativeCode with non-ascii characters in path

[Andrew C. <an...@op...>]

On Sun, 2009-01-25 at 14:18 +0200, Serkan Kaba wrote:
> After I moved my local java-gnome Bazaar repository under a directory
> with Turkish characters, I was unable to run it in place because of
> escaped url usage for file operations

The patch is fine.

I might suggest that you do the test as an alternative if the
first .exists() check fails, thereby saving the decode calls for the
common case where most people don't have the escaping problem?

Just a thought.

Otherwise I will merge it.

AfC
Sydney

Re: [java-gnome-hackers] Bug in loadNativeCode with non-ascii characters in path

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Cowie yazmış:
> I might suggest that you do the test as an alternative if the
> first .exists() check fails, thereby saving the decode calls for the
> common case where most people don't have the escaping problem?

The yield depends on whether File.exists() runs quicker than
URLDecoder.decode() or not. Even if that saves a bit of time, I don't
think it's worth to complicate the code that runs only once on
initialization. If you think it's worth it, I can implement that before
merge.

Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl99dMACgkQRh6X64ivZaILZACdHUg2OIYPebNNnpf2LeA1ZJd6
0HAAn3hY6nBjViHBt4MEpSRfCeFdCTj8
=jfZ3
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Bug in loadNativeCode with non-ascii characters in path

[Andrew C. <an...@op...>]

On Mon, 2009-01-26 at 19:41 +0200, Serkan Kaba wrote:

> The yield depends on whether File.exists() runs quicker than
> URLDecoder.decode() or not.

Indeed.

And none of us can say unless they do some profiling.

>  Even if that saves a bit of time, I don't
> think it's worth to complicate the code that runs only once on
> initialization.

True; and I certainly normally willing to pay a premium on code clarity
& subsequent project maintainability.

This, however, is on the critical path of code that the user has to wait
to complete before their application starts. So it certainly is the sort
of thing that I'd like to keep an eye on. But without hard data I'm not
going to screw you around.

We can merge it as is now.

AfC
Sydney