JRuby

timecop tests fail (because date library is always loaded)

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Gentoo Linux; amd64; JRuby 1.6.7
  • Number of attachments :
    1

Description

This time it's timecop gem that fails tests; the problem is that the date library seems to be always loaded, so when the testsuite checks that the Date and DateTime classes do not exist.. they both exist.

See attached log.

  1. Text File
    tests.log
    28/Feb/12 4:32 AM
    3 kB
    Diego Elio Pettenò

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. JRUBY-6570 autoload :Time, 'time' doesn't work

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Hiro Asari added a comment -

There appears to be some other libraries that are erroneously loaded. I have not examined all of them yet.

$jruby -v; jruby -e 'p RbConfig.ruby'
jruby 1.7.0.dev (ruby-1.9.3-p139) (2012-02-29 548048b) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]
-e:1: Use RbConfig instead of obsolete and deprecated Config.
"/Users/asari/Development/src/jruby/bin/jruby"

$ ruby2.0 -v; ruby2.0 -e 'p RbConfig.ruby'
ruby 2.0.0dev (2012-02-28 trunk 34838) [x86_64-darwin11.3.0]
-e:1:in `<main>': uninitialized constant RbConfig (NameError)
Show
Hiro Asari added a comment - There appears to be some other libraries that are erroneously loaded. I have not examined all of them yet. $jruby -v; jruby -e 'p RbConfig.ruby' jruby 1.7.0.dev (ruby-1.9.3-p139) (2012-02-29 548048b) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java] -e:1: Use RbConfig instead of obsolete and deprecated Config. "/Users/asari/Development/src/jruby/bin/jruby" $ ruby2.0 -v; ruby2.0 -e 'p RbConfig.ruby' ruby 2.0.0dev (2012-02-28 trunk 34838) [x86_64-darwin11.3.0] -e:1:in `<main>': uninitialized constant RbConfig (NameError)
Hide
Permalink
Charles Oliver Nutter added a comment -

This one fails on 1.9.3, so I'm going to ignore it:

  1) Failure:
test_datetime_for_non_dst_to_dst(TestTimeStackItem) [test_time_stack_item.rb:148]:
<#<Date: 2009-12-01 ((2455167j,0s,0n),+0s,2299161j)>> expected but was
<#<Date: 2009-11-30 ((2455166j,0s,0n),+0s,2299161j)>>.
Show
Charles Oliver Nutter added a comment - This one fails on 1.9.3, so I'm going to ignore it: 1) Failure: test_datetime_for_non_dst_to_dst(TestTimeStackItem) [test_time_stack_item.rb:148]: <#<Date: 2009-12-01 ((2455167j,0s,0n),+0s,2299161j)>> expected but was <#<Date: 2009-11-30 ((2455166j,0s,0n),+0s,2299161j)>>.
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, the problem here is likely because we load all of RubyGems on boot, which probably pulls in the date library:

system ~/projects/jruby $ jruby --1.9 -e "p Date"
Date

system ~/projects/jruby $ jruby --1.9 --disable-gems -e "p Date"
NameError: uninitialized constant Date
  const_missing at org/jruby/RubyModule.java:2714
         (root) at -e:1

I'm inclined to close this as wontfix, since MRI is trending toward just loading RG too. But I'll investigate if there's something else we're doing when we load RubyGems that loads 'date' where it would not in MRI.

Show
Charles Oliver Nutter added a comment - Ok, the problem here is likely because we load all of RubyGems on boot, which probably pulls in the date library: system ~/projects/jruby $ jruby --1.9 -e "p Date" Date system ~/projects/jruby $ jruby --1.9 --disable-gems -e "p Date" NameError: uninitialized constant Date const_missing at org/jruby/RubyModule.java:2714 (root) at -e:1 I'm inclined to close this as wontfix, since MRI is trending toward just loading RG too. But I'll investigate if there's something else we're doing when we load RubyGems that loads 'date' where it would not in MRI.
Hide
Permalink
Charles Oliver Nutter added a comment -

Looks like it's our defaults loading too much, perhaps...but we need to load these files in order to patch them for maven support:

2012-04-04T11:39:17.028-05:00: LoadService:     -> rubygems/defaults/jruby
2012-04-04T11:39:17.030-05:00: LoadService:       -> rubygems/config_file
2012-04-04T11:39:17.034-05:00: LoadService:         -> etc
2012-04-04T11:39:17.036-05:00: LoadService:         <- etc - 2ms
2012-04-04T11:39:17.037-05:00: LoadService:         -> Win32API
2012-04-04T11:39:17.039-05:00: LoadService:           -> rbconfig
2012-04-04T11:39:17.039-05:00: LoadService:           <- rbconfig - 0ms
2012-04-04T11:39:17.040-05:00: LoadService:         <- Win32API - 3ms
2012-04-04T11:39:17.041-05:00: LoadService:       <- rubygems/config_file - 11ms
2012-04-04T11:39:17.041-05:00: LoadService:       -> rbconfig
2012-04-04T11:39:17.041-05:00: LoadService:       <- rbconfig - 0ms
2012-04-04T11:39:17.041-05:00: LoadService:       -> jruby/util
2012-04-04T11:39:17.042-05:00: LoadService:       <- jruby/util - 1ms
2012-04-04T11:39:17.042-05:00: LoadService:       -> rubygems/specification
Show
Charles Oliver Nutter added a comment - Looks like it's our defaults loading too much, perhaps...but we need to load these files in order to patch them for maven support: 2012-04-04T11:39:17.028-05:00: LoadService: -> rubygems/defaults/jruby 2012-04-04T11:39:17.030-05:00: LoadService: -> rubygems/config_file 2012-04-04T11:39:17.034-05:00: LoadService: -> etc 2012-04-04T11:39:17.036-05:00: LoadService: <- etc - 2ms 2012-04-04T11:39:17.037-05:00: LoadService: -> Win32API 2012-04-04T11:39:17.039-05:00: LoadService: -> rbconfig 2012-04-04T11:39:17.039-05:00: LoadService: <- rbconfig - 0ms 2012-04-04T11:39:17.040-05:00: LoadService: <- Win32API - 3ms 2012-04-04T11:39:17.041-05:00: LoadService: <- rubygems/config_file - 11ms 2012-04-04T11:39:17.041-05:00: LoadService: -> rbconfig 2012-04-04T11:39:17.041-05:00: LoadService: <- rbconfig - 0ms 2012-04-04T11:39:17.041-05:00: LoadService: -> jruby/util 2012-04-04T11:39:17.042-05:00: LoadService: <- jruby/util - 1ms 2012-04-04T11:39:17.042-05:00: LoadService: -> rubygems/specification
Hide
Permalink
Charles Oliver Nutter added a comment -

Oh, and rubygems/specification has this line:

class Date; end # for ruby_code if date.rb wasn't required

So we're not actually loading the date library, but we're loading enough of RubyGems that its Date stub gets created.

Show
Charles Oliver Nutter added a comment - Oh, and rubygems/specification has this line: class Date; end # for ruby_code if date.rb wasn't required So we're not actually loading the date library, but we're loading enough of RubyGems that its Date stub gets created.
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, I think I have all the details now.

  • Our defaults/jruby.rb file is loaded by RubyGems in order to set our default and monkey-patch a few RG methods for maven support.
  • Some of those methods get defined in Gem::Specification.
  • rubygems.rb defines an autoload for Gem::Specification that loads specification.rb.
  • specification.rb defines a stub Date class.

At the moment there's no way to fix this, since we can't patch the classes in question without loading them, and loading them causes this Date stub to be created.

Show
Charles Oliver Nutter added a comment - Ok, I think I have all the details now. Our defaults/jruby.rb file is loaded by RubyGems in order to set our default and monkey-patch a few RG methods for maven support. Some of those methods get defined in Gem::Specification. rubygems.rb defines an autoload for Gem::Specification that loads specification.rb. specification.rb defines a stub Date class. At the moment there's no way to fix this, since we can't patch the classes in question without loading them, and loading them causes this Date stub to be created.

People

  • Assignee:
    Thomas E Enebo
    Reporter:
    Diego Elio Pettenò
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: