"No such file or directory (IOError)" when JAR file named in java.class.path but not active filesystem

Also, you are squelching the stack trace and the of the IOException, making it very difficult to debug.

Ruby.java

public RaiseException newIOErrorFromException(IOException ioe)

You should be chaining the IOException into the new RaiseException

Interesting points...I think at least we should not squelch the error, we should catch the FNFE as well, and probably use a better way to find resources. Eric, how should we fix the code that's using java.class.path?

Sorry, I read that wrong. I have a small change to catch the ZipException, and I will also add debugging for the IOExceptions that are getting wrapped in IOError. I think perhaps if you have suggestions for a better way to search for resources (other than using classpath) please open a separate bug so we can track that work. Also, it would be helpful if you could provide a short test case we can use to reproduce this.

Test case:

import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import javax.script.ScriptException;

import com.sun.script.jruby.JRubyScriptEngineFactory;

public class JRubyTest {

    public static void main(String[] args) throws ScriptException {
        ScriptEngineFactory scriptEngineFactory = new JRubyScriptEngineFactory();
        ScriptEngine scriptEngine = scriptEngineFactory.getScriptEngine();

        scriptEngine.eval("puts 'Hello World'");
    }
    
}

 
$ java -cp build/classes/:lib/jruby.jar:lib/jruby-engine.jar:lib/script-api.jar JRubyTest
Hello World

$ java -cp build/classes/:lib/jruby.jar:lib/jruby-engine.jar:lib/script-api.jar:bogus.jar JRubyTest
Exception in thread "main" :1: No such file or directory (IOError)
	...internal jruby stack elided...

As far as fixing the code that uses "java.class.path", it depends on what you are trying to do.

I believe the standard way to lookup a resource from the java classpath is to use the methods in the ClassLoader class. For example ClassLoader.getResourceAsStream(), etc.

Will this work for you?

We should probably open a separate bug for changes to the loading process, such as using getResourceAsStream and so on. But you're probably right, if we're not using that now, it would be a good thing to look at.

I'm also all set to fix the missing catch of ZipException, but I have not been able to reproduce it from the command line; it seems like it's something specific to embedding. We're getting to the end of 1.1.3 cycle here, so I don't think this is going to make it in a real form, but I'll add the ZipException catch anyway and we'll come up with a test case post-release.

Fix for the missing ZipException catch committed in r7196. Punting additional work and test case creation to post 1.1.3.

I had a similar issue in 1.1.2. I just upgraded to 1.1.3 and now I'm getting an exception that starts like this:

java.lang.NullPointerException
	at org.jruby.runtime.load.LoadService.findFile(LoadService.java:476)
	at org.jruby.runtime.load.LoadService.findLibrary(LoadService.java:394)
	at org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:259)
	at org.jruby.runtime.load.LoadService.require(LoadService.java:349)
	at org.jruby.javasupport.JavaEmbedUtils.initialize(JavaEmbedUtils.java:86)
        ...

I think this is because the ZipException catch (and the FileNotFoundException catch, for that matter) allow fall-through to line 476 without setting current. Line 476 assumes that current has been set.

BTW, it looks like JRuby would eventually use the ClassLoader if the code in findFile call wasn't erroring out. See, e.g., line 268 of LoadService.

This one-line patch avoids the NPE on line 476 of LoadService

The simple patch I just attached fixes this problem for me. I no longer get the NPE and scripts are required out of the classpath as expected.

This appears to have been fixed for other changes, possibly during the LoadService refactoring I did.