v2.0 Roadmap

[jdantonio]

This gem has been downloaded several million times and still does the job extremely well. It's been a while since it's been updated, however. Ruby and its ecosystem have evolved a lot since then. A 2.0 release will give us an opportunity to remove some old code, better leverage the JVM when used with JRuby, and possibly add new features. Below is a list of a few suggestions. All feedback is welcome.

• Replace compiled Java with JRuby interop: When running under JRuby the WeakReference and SoftReference classes are just wrappers around java.lang.ref.WeakReference and java.lang.ref.SoftReference (here and here). Rather than using compiled code we could use JRuby's excellent interop (as we frequently do in concurrent-ruby).
• Remove support for IronRuby: IronRuby hasn't been updated in nearly 4 years and appears to no longer be under active development. We can prune some code by removing the IronRuby-specific code and default to the pure-Ruby implementation when running under IronRuby.
• Drop support for Ruby 1.8
• Remove any code that checks for the presence of the Thread class: All Ruby interpreters compliant with Ruby 1.9 and above will have threads available. We don't need code branches designed for use when threads are not available.
• Use Ruby's Monitor class: The SafeMonitor class in this gem is not thread-safe on all platforms because it depends on non-atomic operations. The Monitor class in Ruby's standard library has improved since 1.8 and should now be sufficient.
• JRuby implementation of WeakKeyMap: Use JRuby interop to wrap java.util.WeakHashMap
• Ensure thread-safety: This gem was originally designed with thread-safety in mind (see aforementioned SafeMonitor class) but concurrency is tricky. To my knowledge there have been no thread-safety issues but a full audit never hurts. The Java WeakReference and SoftReference classes make no thread-safety guarantees (to my knowledge) and some of the classes in this gem perform multiple non-atomic actions in a single method call (see here). We should either ensure that all the classes in the library are thread safe on all platforms, or we should create thread-safe variations.
• Convert tests to RSpec: I'll admit it--I'm an RSpec snob. Although this change doesn't really make a difference, it does provide consistency with concurrent-ruby which uses RSpec for its tests.

Thoughts? @pitr-ch @mighe @chrisseaton @obrok @lucasallan

[jdantonio]

According to the IronLanguages team, IronRuby does appear to be dead. Too bad.

[lucasallan]

• Remove support for IronRuby
• Drop support for Ruby 1.8
• Remove any code that checks for the presence of the Thread class
• Java implementation of WeakKeyMap
• Use Ruby's Monitor class
• Ensure thread-safety
• Convert tests to RSpec

[pitr-ch]

If you agree I'll turn these into issues. Closing this one.

[pitr-ch]

Thanks @jdantonio