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


Reply via email to