Clayton Wheeler created JRUBY-6658: -------------------------------------- Summary: Problem when setting up an autoload entry, defining a class via require, then redefining the autoload entry Key: JRUBY-6658 URL: https://jira.codehaus.org/browse/JRUBY-6658 Project: JRuby Issue Type: Bug Environment: Mac OS X 10.7.3, Java 1.6.0_31 64-bit server VM, JRuby 1.6.7 and master Reporter: Clayton Wheeler Assignee: Thomas E Enebo Attachments: autoload_repro.tar
Many BioRuby test cases are failing when the whole test suite is run under JRuby, even though most or all individual test scripts run successfully. I have created a minimal test case exhibiting this behavior, which appears to be caused by a JRuby bug relating to autoloads. These tests succeed under MRI (1.9.3-p194) but fail under JRuby 1.6.7 and a recent build from master. When a module creates an autoload entry, and then a child which would be loaded by that entry is instead loaded by directly invoking require, and then the autoload entry is set up again with another call to the parent module's #autoload method, subsequent access to the child module fails with "NameError: uninitialized constant ..." It would appear that the direct definition of a class under a module does not properly remove an autoload map entry; once this state is reached, it is possible for Module#autoload to set up another broken autoload map entry. I have created a RubySpec test case, "Module#autoload entries should NOT raise a NameError when calling #autoload, requiring the module directly, and calling #autoload again", in a pull request (https://github.com/rubyspec/rubyspec/pull/136) submitted to RubySpec. This passes on MRI 1.8.7 and 1.9.3, but not on JRuby 1.6.7 or a recent trunk build. I also have a more elaborate set of scripts used to elucidate the problem, along with their output, attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email