Re: Help me about "Test a New Translation (Japanese)"

----- Original Message ----- 
From: "Kayoko Sawada" <[email protected]>
To: "Philippe Verdy" <[email protected]>; <[email protected]>
Sent: Saturday, November 11, 2006 10:33 PM
Subject: Re: [trans] Help me about "Test a New Translation (Japanese)"


> Phillippe,
> 
> Just for your information,
> this is very small thing and not so important, but I found out one thing.
> Just in case, I send you this information.
> 
> 
> Phill >> Now include the generated .properties file into the LimeWire bundles.
> Phill >> Open "MessagesBundle.jar" with a zip tool, and put the .properties file into it,
> 
> 
> It works successfully WITHOUT doing this.
> Just I put the newly generated .properties file in the same folder.
> That's all.
> LimeWire automatically picks up the new JP.properties and load it.
> Perfectly working now.

It works correctly unless there is already a messages file for the language within the JAR. The search path is currently looking first into the JAR before looking at the directory containing other LimeWire resources. When the JAR is absent (for example in the development version) all messages files are looked into the LimeWire program directory, or more exactly the directories or JARS indicated in the Java's CLASSPATH.

When LimeWire is run using "LimeWire.exe" on Windows, this program sets up the Java's CLASSPATH to include the location of JARs within the CLASSPATH and these JARS come first in that list, even before the directory containing them (this is for security and efficiency).

More generally, a Java application starts and runs much faster and use less OS resources when its resources and classes are packed into a JAR due to MUCH reduced I/O accesses and better management of the OS's data caches for files. This is true for all OSes (the data compression saves lots of I/O, and the CPU cost of decompression is minor face to the gains in I/O accesses).

Note that messages bundles in Java are considered like classes, even if they are implemented as text (*.properties) files instead of binary (*.class) files (the Java class loader first looks for .class binary files and if not found, looks for .properties files in each folder or JAR, before looking into the next JAR or directory locations indicated in the class path). So all messages bundles could as well be a compiled Java class (that implement the "java.util.Properties" interface) instead of text files. If the location order was not stricly followed, there may exist security issues in Java due to the lack of isolation: the single JAR offers such isolation and this is another benefit.

Note that newer versions of Java support a new format for JARs which is different from normal zipped archives. These JARs are optimized for storing .binary class files, and offers even faster performance. Currently LimeWire does not use this new format (at least not for storing its messages bundles which are simply packed into JARs with a zipped format).

_______________________________________________
translate mailing list
[email protected]
http://lists.limewire.org/mailman/listinfo/translate