[ji] eliminate JavaClass usage in favor of Java wrappers#6513
[ji] eliminate JavaClass usage in favor of Java wrappers#6513kares merged 41 commits intojruby:masterfrom
Conversation
keeping it all lazy - no Java proxy-class init on boot
do it the Ruby way avoid too many () brackets
mostly wider converting arguments (not sure it's worth it)
|
I have made quick attempts at this in the past and I support this change. Anything we can do to eliminate that legacy hierarchy of JavaClass and friends would be great! |
|
@headius definitely - this has been very difficult to work with. anyhow, we will need to make a decision whether, despite no longer returning as noted the breakage currently is going to be things like |
+ review Java::JavaClass usage in test:jruby suite
to avoid leaking it thought JRuby's code-base
|
@kares Perhaps the decorations you are adding to make Class look like JavaClass could go in a module? Class could include or prepend the module to pick up the additions. The breakage of things like |
will match the format Class#inspect uses for anonymous classes
deprecate (old) other variants load...Verbose and load...Quiet
with exception wrapping ~ JavaClass.for_name did
previously due JavaClass caching the alternate loading did not trigger a full class setup (which correctly fails since class-loader only loads the one class) leading to an illegal access error trying to setup TestHelper's inner classes
this behavior is no longer supported
... should get a decent review later
kares
force-pushed
the
ji-java-class
branch
2 times, most recently
from
07326ad to
e21f010
Compare
|
I would love to see this land soon. Time to start wrapping up 9.3 for reals. |
there's still an issue of potential double initializing a proxy class if we start first with initializing a java.lang.Class proxy it ends up setting up two proxy instances
not relying on getRuntime() will allow unplugging these classes
now a java.lang.Class alias this would need for_name patching
Jruby commit jruby/jruby#6513 included cleanup to eliminate JavaClass usage and will log any use of such to stdout. As part of plugin registration, a check is made against the plugin class to determine if it meets the requirements of a Java plugin. From running tests against native Java plugins, this check doesn't appear to be required
Jruby commit jruby/jruby#6513 included cleanup to eliminate JavaClass usage and will log any use of such to stdout. As part of plugin registration, a check is made against the plugin class to determine if it meets the requirements of a Java plugin. From running tests against native Java plugins, this check doesn't appear to be required
Jruby commit jruby/jruby#6513 included cleanup to eliminate JavaClass usage and will log any use of such to stdout. As part of plugin registration, a check is made against the plugin class to determine if it meets the requirements of a Java plugin. From running tests against native Java plugins, this check doesn't appear to be required
2 participants
JRuby's Java integration has been using a custom
JavaClassruby class to represent ajava.lang.Classinstance.However this isn't super easy to work with (personally I have always find it quite confusing given the existing complexity of proxy modules/classes) nor has been 100% consistent e.g.
obj.java_classdepending on the proxy type (interface impl, Java sub-class in Ruby) might have returned a proxy instead of theJavaClassinstance (returned fromjava.lang.String.java_class).The proposal here is to start returning
java.lang.Classinstance Java proxy wrappers everywhere (alljava_classcalls), for compatibility all of the customJavaClassRuby API is supported onjava.lang.Classand others (there'sJavaField,JavaConstructorinstancesJavaClassmethods where returning which will be 'emulated' usingjava.lang.reflect.Field,java.lang.reflect.Constructor).