The old solution used #java_class, which works for Java class proxies, which is what e.g. Java::OrgApacheHadoopIo::BytesWritable gives you.
However, it neither supports passing a Java::JavaLang::Class instance (as it will use java.lang.Class as name instead of the desired class), and also does support classes exposed to Ruby.
The last use case would mainly be beneficial in order to support implementations that extend RubyObject (and therefore natively expose both a Hadoop front and a JRuby front).
While I realize more changes to the DSL are probably not desired at this point, I would argue that this is more of a bug-fix and less of a new feature, but I guess you could argue both ways.
The old solution used #java_class, which works for Java class proxies, which is what e.g. Java::OrgApacheHadoopIo::BytesWritable gives you.
However, it neither supports passing a Java::JavaLang::Class instance (as it will use java.lang.Class as name instead of the desired class), and also does support classes exposed to Ruby.
The last use case would mainly be beneficial in order to support implementations that extend RubyObject (and therefore natively expose both a Hadoop front and a JRuby front).
While I realize more changes to the DSL are probably not desired at this point, I would argue that this is more of a bug-fix and less of a new feature, but I guess you could argue both ways.