@ggongaware I do not believe this to be a bug since Character.getName(int codePoint) in Java takes a single argument, the code point.

This is the expected exception when a call is made without the necessary arguments, and the behavior is consistent with JRuby 1.7.21

When calling get name on other random java classes, example:

Java::JavaIo::ByteArrayInputStream.name

you get a string with the class name 'Java::JavaIo::ByteArrayInputStream'

shouldn't Java::JavaLang::Character.name with zero arguments do that same?

@ggongaware AH, I see the confusion! Sorry for misunderstanding what method you were trying to invoke previously.

Since getName() is overloaded it's a bit weird to invoke the right method properly. We do have the #java_send method (this blog post covers pretty well) but that still doesn't work quite right when we try to use it on Java::JavaLang::Character since this appears to be a wrapped class object.

To get the expected result I executed:

[20] pry(main)> Java::JavaLang::Character.to_java.java_send(:getName)
=> "Java::JavaLang::Character"
[21] pry(main)> 

I'm not sure if there's a better way around it, it's awkward behavior that's for sure

Here's a monkey patch I'm using to keep an older library happy:

    Java::JavaLang::Character.class_eval do
       def self.name(*args)
         if args.length > 0
           getName(*args)
         else
          'Java::JavaLang::Character'
         end
       end
    end

re-opening as I think this one should be reconsidered for fixing with a slight JI layer refactoring. in this case the mapping of name -> getName is confusing (and a little weird name(xxx)) I believe getName should only be mapped if it takes zero arguments - normal getter.

@kares the original intent was to only shortcut javabean conventions and not to when there was a conflict. I find it weird that name(a) was ever created

@enebo agreed, already do have some bigger WiP changes - one of which is making name work for packages (by default) - still needs more work before ready for feedback whether to proceed there.

but this one should be simple to fix, is it ok to make such change on 9K now or should it be on hold ?

@kares I think this can be fixed now on 9k.

I don't think there's a good fix here. The shortcutting of getName to name would break a key method on the proxy classes. There are many libraries like rspec that expect to be able to call name to get the name of the class.

We don't bind the shortcut because of the priority logic that favors methods already defined at the Ruby level over aliases of the Java methods. I think it's just better to tell folks to call getName here.

@headius @kares I am really confused what the problem is now. We never made shorthand methods for methods which did not follow Javabean conventions. ...but the original reporter seemingly implies we were shorthanding a getName which took a single argument? If so then this is a bug right? Something which can and should be fixed? Or @headius are you saying we need a mandatory 'name' method on all proxies so we should never short-hand getName ever. Either way something should change right?

Adding 'name' to java packages is a completely different issue and not related to this per se?

@headius me too ... let me try to explain a little more: currently the static Character.getName(String) is aliased by JI to self.name which obviously conflicts a Ruby method - we agreed that the solution in this case touches a 'bigger' problem since it's kind of ugly to map non-true getters (those that accept args) to a ruby reader (self.name(str)) - which is currently happening. only "true" bean-style getters/setters should end up being mapped as readers/writers.

turns out I was a little wrong - the code already checks if get/set methods are bean-style and only adds Ruby reader/writer methods in such cases. here its Character.getName(int codepoint) which actually is a match for the (bean-style) indexed property convention ... getFoo(int) --> foo(i) that is handled.

the easy fix requires removing that support - people shouldn't be using that much bar.foo(0) looks as a weird alias for bar.getFoo(0) + setters are not mapped - only getters (they would look even weirder) and it wasn't ever documented

So what's the verdict here? What still needs to be done, @kares?

@headius there's a PR open for review as I wanted your or @enebo's approval #3328

If no one else objects to @kares PR I will land this right after 9.0.2.0 is out just in case we figure out something does use this afterall (the java beans indexed getter shorthand). I highly doubt anyone is using this because they knew it existed as a feature. It might be someone stumbled on it so I would like this to bake for a full point release in hopes of discovering any users (I doubt there are any though).

👍

The PR is good to go but I do not want to land it immediately before 9.0.4.0 so we should land right after release. (@kares you can merge your own PR for this once 9.0.4 is out).

thx, will do one once I see the pom versions updated to 9.0.5.0-SNAPSHOT on master. ..