Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
alyssais opened this issue Feb 1, 2017 · 4 comments · Fixed by #4570
Closed

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

alyssais opened this issue Feb 1, 2017 · 4 comments · Fixed by #4570

Comments

@alyssais
Copy link

alyssais commented Feb 1, 2017

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
Copy link

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
Copy link
Author

alyssais commented Apr 8, 2017

@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
Copy link
Member

kares commented Apr 15, 2017

@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
Copy link
Member

kares commented Apr 17, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants