Windows suffers from a similar problem with Java, which was where I got the idea to try this.

A Jar file is just a compressed set of Java classes. You can invoke them in the terminal via java -jar, just like if it were a class.

The LimeWire "app" that you see *kind of* does the same thing.

Anyways:

1. Open Terminal
2. Type "java -jar " and drag in the file "LimeWire.jar" in the LimeWire folder.
i.e. "java -jar /Applications/Limewire/LimeWire.jar"

LimeWire will now start up.

DO NOT quit Terminal, and try to live with the fact that instead of the LimeWire icon in the dock, you get Apple's generic Java Application icon.

What was using 70-80% on my dual 1Ghz is now using between 5 and 20.

Have fun!

Mike

Woops, look's like there's nothing wrong with quitting Terminal while LimeWire runs.

Chip,

To repeat my reply to Dan on his port, your fix seems to be working on my G4/400MHz.

This is clearly a programming bug -- how do we submit a bug report?

Beats me jannuss. In the meantime, I'd just use my method, since it's not to obtrusive when you hide the Terminal.

Also, I was wrong about quitting Terminal. Ending the Java process may quit Limewire.

This is extremely odd behavior. It's possible that something in running it from the command line prevents you from becoming an Ultrapeer (you can see your Ultrapeer status in the connections tab in the lower left -- if it says "Ultrapeer," then you're an Ultrapeer, otherwise you're a "leaf").

Otherwise, there should be no difference between running LimeWire from the command line and running it from the alias.

It's also extremely odd behavior that LimeWire does what I found the fix for in the first place!

Launching the LimeWire app should just be a GUI front end that tells the system:

java -jar /Applications/LimeWire/LimeWire.jar

Which it musn't be, because then there shouldn't be any problems with using either method. The app itself is definitely not just an alias to the Java call. It's much too big a file for that.

If LimeWire has problems with this, then LimeWire is being programmed extremely poorly. There are a number of other reasons for this being true, besides this. Read around the forums and you'll see.

People shouldn't be writing Java apps if they don't understand the basic idea of what Java is for.

Actually the proper command for running LimeWire should be
java -jar /Applications/LimeWire/RunLime.jar

The problem is not caused by LimeWire's java code, but either by the run script or MacOSX' WindowManager, that does not properly handle the command to start the java app.

Since the WindowManager is the task that uses 70%-80% of the cpu resources I assume this is a MacOSX bug.

Ahh...yeah. Yes, LimeWire wraps the call to java -jar RunLime.jar in the standard Apple app builder.

Thanks.

trap_jaw is correct that the underying command is to:

java -jar /Applications/LimeWire/RunLime.jar

We'll investigate the Window Manager issue more thoroughly. On our 10.1.2 system, we saw no difference between the command line execution and the normal execution, but I'll check on Jaguar and have a look at all processes involved.

Thanks!

CptChipJew-

Just to clarify, the call to java -jar RunLime.jar does not simply launch the ui -- it launches the entire java application, including all connection threads, TCP and UDP listening threads, etc. OS X has it's own custom method of launching java applications (launching java applications is basically os-specific because there are multiple ways of executing processes via aliases, shortcuts, exes, etc, on different operating systems). In LimeWire on OS X, we use the executable automatically generated by InstallAnywhere. On Windows, I wrote a custom executable to locate the latest java executable and run it.

Thanks.