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. tests.log
        3 kB
        Diego Elio Pettenò

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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ò
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: