Well I don't know if anyone of you folks has actually read the Jar-Specification, but I do know that noone really uses the information in it. If these two lines were included in the LimeWire.jar's Manifest File (Oh, I forgot, LimeWire.jar does not even have a Manifest File! Why not? Include one!):

Class-Path: collections.jar
Main-Class: a/a/a/b/Main

then LimeWire could be run on every platform that has a JRE 1.2 or higher installed by just typing "java -jar LimeWire.jar". On Windows and Solaris you could run LimeWire.jar by clicking on it just like any native executable. On Windows, you can create shortcuts to Lime by just dragging LimeWire.jar to the Desktop with the right mouse button and select "create shortcut". Why do you make things so complicated? Noone needs to start "RunLime.class" or to type "java -cp LimeWire.jar;collections.jar a.a.a.b.Main."

PS: Can you tell me why you bundle a windows dll with the java version of LimeWire? Or with the linux version? i don't get it, sorry! if i wanted improved performance on windows, i would download the windows version, not the java version.

I have wanted that for a long time myself. Not sure why we still don't do it other than there is some trick to properly creating the manefest file for inclusion into the jar (perhaps unix/dos mode file settings (cr/lf)). I have built jars that do work as you mention although generally with collections.jar content included into the LimeWire.jar. collections.jar will hopefully go away soon since it is a version of Java 1.2 collections for use with Java 1.1 (needed for Macs).

The dll is there because we don't build separate jars and some LimeWireOther.zip users are Windows users.

-greg

RunLime.class was added to allow the jar to be updated before loading it.

-greg