private and private :foo have different semantics when compiling to Java

[alyssais]

Environment

jruby -v

jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 25.112-b16 on 1.8.0_112-b16 +jit [darwin-x86_64]

uname -a

Darwin zoroark 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64

Expected Behavior

class Foo
  private
  def foo?
    true
  end
end

should be compiled with jrubyc --java to the same Java as

class Foo
  def foo?
    true
  end
  private :foo?
end

(The foo? method should not be generated in Java.)

Actual Behavior

JRuby tries to compile the first example's foo? method to Java, which fails because -? methods aren't supported in Java.

[snood1205]

I get an error while attempting to compile the second version as well. Shouldn't it compile to something equivalent to

public class Foo {
    private RubyObject isFoo() {
        return true;
    }
}

in both scenarios? I feel like the method_name? paradigm in ruby is always isMethodName in Java. That's just my two cents.

[alyssais]

@snood1205 I don't think so — I don't think there's any reason for a private Ruby method to be exposed to Java at all.

[kares]

@alyssais you would need to look at the internals to understand why its compiling everything - basically the assumption is that the interpreter is left behind and a new Java class is generated -> thus all methods (even private ones) need to be available. that was mixing 🍎 and 🍊 anyways since this is jrubyc and in Ruby private methods are not that far away (obj.send(:private_method)) this does not need much explaining.

in both scenarios? I feel like the method_name? paradigm in ruby is always isMethodName in Java.

that is a convention when making Java methods accessible in Ruby, this is something else (no JI involved).

[kares]

looked into and realized I did not know about jrubyc --java doing smt completely different than jrubyc.
I understand your concerns/hints now (and find new issues - attr_ methods not being considered) but I am not yet sure what would be the best way to fix. would go with get/isFoo but that would mean 2 assumptions :

• foo? would need to always return a true/false - follow the convention
• one would need to be able to detect attr_readers/writers as getters/setters