Wow, this is goofy. Confirmed in 1.4dev that it still works like this:

~/projects/jruby ➔ javac -cp lib/jruby.jar MyAppExtService.java 

~/projects/jruby ➔ jar cf my_app_ext.jar MyAppExtService.class 

~/projects/jruby ➔ mkdir foo

~/projects/jruby ➔ mv my_app_ext.jar foo

~/projects/jruby ➔ jruby -e "require 'foo/my_app_ext'"

~/projects/jruby ➔ jruby -e "require 'foo/my_app_ext.jar'"

~/projects/jruby ➔ mv foo/my_app_ext.jar .

~/projects/jruby ➔ jruby -e "require 'my_app_ext.jar'"
hello

~/projects/jruby ➔ cat MyAppExtService.java 
import org.jruby.runtime.load.BasicLibraryService;
import org.jruby.Ruby;
import java.io.IOException;

public class MyAppExtService implements BasicLibraryService {
	public boolean basicLoad(Ruby runtime) {
		System.out.println("hello");
		return true;
	}
}

Actually I'm not sure if this is a bug.

There are two classes that can load the jar. ClassExtensionLibrary fails because it tries to load a class into a package, in this case "foo/MyAppExtService", JarredScript also fails because it searchs for the attribute "Ruby-Init" into the jar manifest.

So a workaround, or the correct behaviour would be to move the class to a package called 'foo'. And a possible fix would be to remove the directory path to load the class when we work with jar files.

If the fix is fine I can send a patch in a while.

Ahh good point. The line between "bug" and "badly specified behavior" is pretty fine, but I think we agree something needs to be corrected here. Toss over a proposed patch and we'll see how it looks. This loading logic obviously needs to be better specified, regardless.

this patch just tries to load the same class without the full package name if it fails with the package name. It also adds a test case and a jar extension as a fixture.

Actually I'm not sure if this is the best solution but the documentation neither is well specified.

Punting to 1.x+ again...this needs to be examined a bit better and we need to formalize the rules/guidelines for jar-based extensions and how we load them.