Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.3
    • Fix Version/s: JRuby 1.5
    • Component/s: Intro, Java Integration
    • Labels:
      None
    • Environment:
      OS X 10.5.8
    • Number of attachments :
      0

      Description

      When using threadify to create a multi-threaded script where a class uses the Java/Ruby integration layer and where imports are package imports such as:

      import org.apache.http

      And that class only gets instantiated inside the thread block, the following warning is displayed at start up for a number of classes that are loaded:

      /usr/local/lib/jruby-1.3.0/lib/ruby/site_ruby/1.8/builtin/javasupport/core_ext/module.rb:27 warning: already initialized constant HttpHost

      Where HttpHost may be a variety of class names.

      I showed this to Charles tonight at RubyConf 2009, and he said he thought it could be fixed inside the JRuby code.

        Activity

        Hide
        Anthony Eden added a comment -

        Sorry, the version should be Affects Version: JRuby 1.3, not Fix Version: JRuby 1.3.

        Show
        Anthony Eden added a comment - Sorry, the version should be Affects Version: JRuby 1.3, not Fix Version: JRuby 1.3.
        Hide
        David Calavera added a comment -

        Just notice that module.rb changed a little bit in version 1.4 and the code that actually shows the messaage is the next one, in line 37:

          JavaUtilities.create_proxy_class(constant, java_class, self)
        

        Anthony, could you attach a test case or a script to check this problem?

        Show
        David Calavera added a comment - Just notice that module.rb changed a little bit in version 1.4 and the code that actually shows the messaage is the next one, in line 37: JavaUtilities.create_proxy_class(constant, java_class, self) Anthony, could you attach a test case or a script to check this problem?
        Hide
        Charles Oliver Nutter added a comment -

        We've fixed other cases like this in the past, but this should be fixed in 1.5. The problem here is that the lazy lookup and constantification of classes from a package import is not thread-safe and does not quietly ignore when the constant has already been assigne the same class in another thread.

        Here's a dumb example that causes it:

        require 'java'
        threads = []
        100.times do
          threads << Thread.new(Object.new) do |o|
            class << self
              import java.util
              ArrayList; Vector; HashMap; Collection; List; Map
            end
          end
        end
        
        threads.map(&:join)
        

        I'm marking this intro, since the logic for package imports isn't terribly complicated, and it could be an easy one for someone to fix.

        Show
        Charles Oliver Nutter added a comment - We've fixed other cases like this in the past, but this should be fixed in 1.5. The problem here is that the lazy lookup and constantification of classes from a package import is not thread-safe and does not quietly ignore when the constant has already been assigne the same class in another thread. Here's a dumb example that causes it: require 'java' threads = [] 100.times do threads << Thread.new(Object.new) do |o| class << self import java.util ArrayList; Vector; HashMap; Collection; List; Map end end end threads.map(&:join) I'm marking this intro, since the logic for package imports isn't terribly complicated, and it could be an easy one for someone to fix.
        Hide
        Charles Oliver Nutter added a comment -

        I fixed this by making the actual const set be quiet on overwrites (for this specific case) but to add a warning (for this specific path) if a constant is going to be overwritten with a different value. So this quiets your warnings, and should never warn unless there's something actually being overwritten in a destructive way. Pushed in 68f4623...and I have no idea how we'd test this, so I didn't.

        Show
        Charles Oliver Nutter added a comment - I fixed this by making the actual const set be quiet on overwrites (for this specific case) but to add a warning (for this specific path) if a constant is going to be overwritten with a different value. So this quiets your warnings, and should never warn unless there's something actually being overwritten in a destructive way. Pushed in 68f4623...and I have no idea how we'd test this, so I didn't.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Anthony Eden
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: