JRuby

autoload :Time, 'time' doesn't work

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.6.7
  • Fix Version/s: JRuby 1.7.0.pre1
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows 7
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

Kernel.autoload doesn't seem to work with the Time class, while Module.autoload does work.

% jruby -v
jruby 1.6.7 (ruby-1.8.7-p357) (2012-02-22 3e82bc8) (Java HotSpot(TM) Client VM 1.6.0_17) [Windows 7-x86-java]

Run the following script:

autoload :Bar, 'bar'
puts autoload?(:Bar)

autoload :Time, 'time'
puts autoload?(:Time)

module Foo
end

Foo.autoload :Time, 'time'
puts Foo.autoload?(:Time)

I see the following output:

bar
nil
time

when I would expect to see the following:

bar
time
time

Unit test file attached to demonstrate the bug.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. JRUBY-6508 timecop tests fail (because date library is always loaded)

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

Confirmed on master.

Show
Charles Oliver Nutter added a comment - Confirmed on master.
Hide
Permalink
Charles Oliver Nutter added a comment -

Looks like this is a problem with how it finds the Time constant. I'm a little confused by this, though...since Time is a standard toplevel class, how does autoload ever trigger for it?

Show
Charles Oliver Nutter added a comment - Looks like this is a problem with how it finds the Time constant. I'm a little confused by this, though...since Time is a standard toplevel class, how does autoload ever trigger for it?
Hide
Permalink
Jeff Solomon added a comment -

I thought it had to do with the fact that the Time class is already loaded at startup even though time.rb isn't loaded by default. time.rb extends the standard top level class with new methods.

So I checked Date, which has the same situation and it has the same behavior. Perhaps autoloading a class for which:

Object.const_defined?('Time')

is already true will have this behavior?

Show
Jeff Solomon added a comment - I thought it had to do with the fact that the Time class is already loaded at startup even though time.rb isn't loaded by default. time.rb extends the standard top level class with new methods. So I checked Date, which has the same situation and it has the same behavior. Perhaps autoloading a class for which: Object.const_defined?('Time') is already true will have this behavior?
Hide
Permalink
Hiro Asari added a comment -

This sounds like a duplicate of JRUBY-6508.

Show
Hiro Asari added a comment - This sounds like a duplicate of JRUBY-6508 .
Hide
Permalink
Charles Oliver Nutter added a comment -

Jeff: I think you're right. There must be some missing detail in our autoloading logic whereby we should not look at toplevel constants.

Hiro: You may be right, if timecop uses autoloading to pull in missing features.

I still find it rather odd that you can define an autoload for a constant that would resolve, even if that resolution happens at the top Object level.

Show
Charles Oliver Nutter added a comment - Jeff: I think you're right. There must be some missing detail in our autoloading logic whereby we should not look at toplevel constants. Hiro: You may be right, if timecop uses autoloading to pull in missing features. I still find it rather odd that you can define an autoload for a constant that would resolve, even if that resolution happens at the top Object level.
Hide
Permalink
Charles Oliver Nutter added a comment -

Rubinius fails this in the same way we do...

Show
Charles Oliver Nutter added a comment - Rubinius fails this in the same way we do...
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, so the actual problem here is due to calling autoload as a Kernel method from within an instance method.

system ~/projects/jruby $ ruby1.9.3 -e "class Foo; def go; autoload :Bar, 'bar'; end; end; f = Foo.new; f.go; p Foo.autoload? :Bar"
"bar"

system ~/projects/jruby $ jruby -e "class Foo; def go; autoload :Bar, 'bar'; end; end; f = Foo.new; f.go; p Foo.autoload? :Bar"
nil

In Kernel#autoload we call a method getModuleForAutoload to determine the module in which the autoload should be defined. If self is a module or class, we use that. Otherwise, we try to define the autoload on Object directly. That causes the Time autoload to fail here because Time already exists on Object.

MRI uses the current cbase class/module as the location to define the class for autoload. This allows it to define the autoload on the current object's class.

Show
Charles Oliver Nutter added a comment - Ok, so the actual problem here is due to calling autoload as a Kernel method from within an instance method. system ~/projects/jruby $ ruby1.9.3 -e "class Foo; def go; autoload :Bar, 'bar'; end; end; f = Foo.new; f.go; p Foo.autoload? :Bar" "bar" system ~/projects/jruby $ jruby -e "class Foo; def go; autoload :Bar, 'bar'; end; end; f = Foo.new; f.go; p Foo.autoload? :Bar" nil In Kernel#autoload we call a method getModuleForAutoload to determine the module in which the autoload should be defined. If self is a module or class, we use that. Otherwise, we try to define the autoload on Object directly. That causes the Time autoload to fail here because Time already exists on Object. MRI uses the current cbase class/module as the location to define the class for autoload. This allows it to define the autoload on the current object's class.
Hide
Permalink
Charles Oliver Nutter added a comment -

Oops, I committed a fix for this one instead of for JRUBY-6508. Here's the commit:

commit 195b90243b343619b462324c0eafcf97531b1f50
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Wed Apr 4 10:56:43 2012 -0500

    Fix JRUBY-6570: autoload :Time, 'time' doesn't work
    
    Instead of always using Object when calling autoload from an
    instance method, we use self's real class (skipping singletons)
    as the autoload location. This isn't exactly how MRI does it
    (they use cbase, which I think is euivalent to 1.8's ruby_class),
    but it should be correct for the majority of cases.
Show
Charles Oliver Nutter added a comment - Oops, I committed a fix for this one instead of for JRUBY-6508 . Here's the commit: commit 195b90243b343619b462324c0eafcf97531b1f50 Author: Charles Oliver Nutter <headius@headius.com> Date: Wed Apr 4 10:56:43 2012 -0500 Fix JRUBY-6570: autoload :Time, 'time' doesn't work Instead of always using Object when calling autoload from an instance method, we use self's real class (skipping singletons) as the autoload location. This isn't exactly how MRI does it (they use cbase, which I think is euivalent to 1.8's ruby_class), but it should be correct for the majority of cases.
Hide
Permalink
Charles Oliver Nutter added a comment -

Reopening to resolve as fixed, since this issue may be slightly different from JRUBY-6508.

Show
Charles Oliver Nutter added a comment - Reopening to resolve as fixed, since this issue may be slightly different from JRUBY-6508 .
Hide
Permalink
Jeff Solomon added a comment -

Thank you Charles!

Show
Jeff Solomon added a comment - Thank you Charles!

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Jeff Solomon
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: