jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • JRuby
  • JRUBY-415

All Java classes bound into Ruby should provide an allocator/initialize combo or documentation why they do not

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: JRuby 0.9.0, JRuby 0.9.1, JRuby 0.9.2, JRuby 0.9.8, JRuby 0.9.9, JRuby 1.0.0RC1, JRuby 1.0.0RC2, JRuby 1.0.0RC3
  • Fix Version/s: JRuby 1.1b1
  • Component/s: Core Classes/Modules
  • Labels:
    None

Description

Multiple Java-based classes in JRuby do not provide the appropriate allocator/initializer combination necessary for things like Class.new and marshalling to work correctly. In most cases, I have set these to use the NOT_ALLOCATABLE_ALLOCATOR, but this must be fixed for all types.

I list the ones I know of here.

NativeException: If NativeException is expected to be used from Ruby code, it should provide a real allocator and initializer to be used. Otherwise Class.new will fail, as will marshalling.

RubyThreadGroup: ThreadGroup can't be marshalled, but it could be Class.new'ed. We may also want to replace RubyThreadGroup with lightweight state.

JavaClass, JavaMethod, JavaConstructor, JavaField: May or may not need the correct allocate/initialize combo, since they're primarily used internally.

JavaObject: see JRUBY-414

RubyMethod, RubyUnboundMethod: Method and UnboundMethod can't be instantiated, but examine whether the allocate/initialize combo makes sense here.

RubyStruct: Struct is a little weird, since it creates new classes. Structs are also very likely to be candidates for marshalling. Currently the top-level Struct class uses NOT_ALLOC.. but this likely will interfere with struct instances being marshallable. Fix.

Process::Status can't be instantiated, but it could potentially be marshalled. Confirm correct behavior and fix.

NilClass: I set up nil to have an allocator that just returns the nil object from the provided runtime. I'm not sure if this is necessary or correct. NOT_ALLOC might be better?

File::Stat: definitely needs to be fixed.

Generator: ??

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. JRUBY-6103 allocator undefined for NativeException

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Charles Oliver Nutter added a comment - 03/Apr/07 11:14 PM

Finish for 0.9.9. Most of this has already been done.

Show
Charles Oliver Nutter added a comment - 03/Apr/07 11:14 PM Finish for 0.9.9. Most of this has already been done.
Hide
Permalink
Charles Oliver Nutter added a comment - 20/Apr/07 12:13 AM

None of these have been reported as issues (except one or two folks mentioning that Thread actually tries to marshal), so I'm bumping it to 1.0. We need to tidy these up, but they don't appear to be affecting anyone.

Show
Charles Oliver Nutter added a comment - 20/Apr/07 12:13 AM None of these have been reported as issues (except one or two folks mentioning that Thread actually tries to marshal), so I'm bumping it to 1.0. We need to tidy these up, but they don't appear to be affecting anyone.
Hide
Permalink
Charles Oliver Nutter added a comment - 16/May/07 5:43 PM

Punting to post-1.0, barring any reported problems that make it critical. If there's anything to do, we'll do it. Otherwise, it's not hurting anyone.

Show
Charles Oliver Nutter added a comment - 16/May/07 5:43 PM Punting to post-1.0, barring any reported problems that make it critical. If there's anything to do, we'll do it. Otherwise, it's not hurting anyone.
Hide
Permalink
Charles Oliver Nutter added a comment - 30/Sep/07 11:55 AM

Most cases were fixed; others have never been reported or will be different in the future (like new Java Integration stuff).

Show
Charles Oliver Nutter added a comment - 30/Sep/07 11:55 AM Most cases were fixed; others have never been reported or will be different in the future (like new Java Integration stuff).
Hide
Permalink
Charles Oliver Nutter added a comment - 09/Jun/11 11:12 PM

For anyone that runs into additional cases, you can use _load and _dump to get around allocator issues:

class NativeException
  def _dump(*)
    'whatever'
  end

  def self._load(str)
    nil
  end
end

begin
  java.lang.System.getProperty(nil)
rescue NativeException => e
  p Marshal.load(Marshal.dump(e))
end

The contract of _dump is that it returns a String containing everything you need to _load later on. _dump receives as an argument the "depth limit" for dumping, i.e. the most levels the caller intends for the object graph to reach. The contract of _load is that it receives that String and you use it to reconstitute your object in whatever way is appropriate.

This example dumps nonsense and has load simply return nil, so NativeExceptions in the marshal stream will come back as nil; but it could also marshal an exception name or the contained Java exception itself. Choose your own adventure.

Show
Charles Oliver Nutter added a comment - 09/Jun/11 11:12 PM For anyone that runs into additional cases, you can use _load and _dump to get around allocator issues:
class NativeException
  def _dump(*)
    'whatever'
  end

  def self._load(str)
    nil
  end
end

begin
  java.lang.System.getProperty(nil)
rescue NativeException => e
  p Marshal.load(Marshal.dump(e))
end
The contract of _dump is that it returns a String containing everything you need to _load later on. _dump receives as an argument the "depth limit" for dumping, i.e. the most levels the caller intends for the object graph to reach. The contract of _load is that it receives that String and you use it to reconstitute your object in whatever way is appropriate. This example dumps nonsense and has load simply return nil, so NativeExceptions in the marshal stream will come back as nil; but it could also marshal an exception name or the contained Java exception itself. Choose your own adventure.
Hide
Permalink
Jim Crossley added a comment - 10/Jun/11 9:32 AM

With DRb, I wanted exceptions generated on the server to be caught on the client, so this works well:

class NativeException
def _dump
Marshal.dump( [cause, backtrace] )
end
def self._load(str)
exception, trace = Marshal.load(str)
meta = class << exception; self; end
meta.send(:define_method, :backtrace) { trace }
exception
end
end

Show
Jim Crossley added a comment - 10/Jun/11 9:32 AM With DRb, I wanted exceptions generated on the server to be caught on the client, so this works well: class NativeException def _dump Marshal.dump( [cause, backtrace] ) end def self._load(str) exception, trace = Marshal.load(str) meta = class << exception; self; end meta.send(:define_method, :backtrace) { trace } exception end end

People

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

Dates

  • Created:
    07/Jan/07 12:41 AM
    Updated:
    18/Jan/12 12:30 AM
    Resolved:
    30/Sep/07 11:55 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.