Marshal.dump yields different value after adding/removing instance variables (and disagrees with MRI) -----------------------------------------------------------------------------------------------------
Key: JRUBY-6182 URL: https://jira.codehaus.org/browse/JRUBY-6182 Project: JRuby Issue Type: Bug Components: Ruby 1.9.2 Affects Versions: JRuby 1.6.5 Environment: Windows 7, 32-bit Java 1.6.0_29 Reporter: Matt Keveney Assignee: Thomas E Enebo I'm not sure whether this is a bug in JRuby, or merely an oddity that surfaced due to an unconventional use of Marshal. JRuby with --1.9: irb(main):001:0> h = {} => {} irb(main):002:0> Marshal.dump h => "\x04\b{\x00" irb(main):003:0> h.instance_eval { @myvar = 1234 } => 1234 irb(main):004:0> Marshal.dump h => "\x04\bI{\x00\x06:\v@myvari\x02\xD2\x04" irb(main):005:0> h.instance_eval { remove_instance_variable :@myvar } => 1234 irb(main):006:0> Marshal.dump h => "\x04\bI{\x00\x00" Note that h is dumped differently after the instance variable has been removed, though this bytestream will still yield an equivalent object. It seems to be specifying a zero-length list of instance variables. MRI version 1.9.2 irb(main):001:0> h = {} => {} irb(main):002:0> Marshal.dump h => "\x04\b{\x00" irb(main):003:0> h.instance_eval { @myvar = 1234 } => 1234 irb(main):004:0> Marshal.dump h => "\x04\bI{\x00\x06:\v@myvari\x02\xD2\x04" irb(main):005:0> h.instance_eval { remove_instance_variable :@myvar } => 1234 irb(main):006:0> Marshal.dump h => "\x04\b{\x00" Note that MRI completely removes the instance variable tag from the byte stream. I found this this using Nanoc with Jruby. Nanoc computes a SHA1 hash on the Marshal.dump output to detect object alterations from one run to the next. This strategy only works if Marshal is guaranteed to emit an _identical_ bytestream for equivalent objects. Should Marshal be expected to do so? ...or is Nanoc expecting too much? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email