Rspec problem with jruby

I’ve tested it against trunk r7971, the problem still persists.
Filled a bug report for it,
http://jira.codehaus.org/browse/JRUBY-3099

Luis Landeiro

Charles Oliver N. wrote:

issue can be tested.
Account
=> >> User.first.accounts.max{|x,y| puts x.class; puts y.class; -1}
[#<Account id: 2, title: nil, user_id: 1, created_at: “2008-10-29
13:54:30”, updated_at: “2008-10-29 13:54:30”>, #<Account id: 1, title:

Cheers
http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I suspect this is a still-open issue where calling abstract methods (or
calling methods that call abstract methods) from within the constructor
or initialize does not work. The sequence of events that sets up the
Ruby and Java sides of the object is such that there’s no way for both
to be initialized by the time an abstract method is called during
construction. If the Ruby side is initialized first, it then initializes
the Java side, but that would mean you could not call any Java methods
from within initializers. If the Java side is initialized first, it will
be available for calling against in the Ruby initializer; but abstract
methods it implements will not be callable yet.

Is wakeupOn or any methods it would call lead into an abstract method
implemented in Ruby code, like processCondition?

  • Charlie

john casu wrote:

p "in process condition\n"

listing them and forcing them to be accessible so long as security


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I think I know what the problem in this case might be…

In the java class Behavior, initialize is an abstract function, which
the user has to implement (there’s another bug in my code, but that’s
irrelevant to this discussion), whereas in jruby it’s the class
constructor.

I’m wondering what would happen in this case.

Charles Oliver N. wrote:

Is wakeupOn or any methods it would call lead into an abstract method
implemented in Ruby code, like processCondition?

bug on my part here. processCondition should be called processStimulus.
Fixing this didn’t change the bug.

processStimulus is an abstract function inherited from the Java class,
which in this case (and this is the entire point of this exercise) is
implemented in Jruby.

but wakeupOn doesn’t appear to directly call processStimulus, but sets
things up for it to be called when the wakeup condition matures.

and ran my code. Still busted, but given that I couldn’t find a
Charles Oliver N. wrote:

end
Are the missing methods protected? There’s a standing bug in 1.1.4
http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Charles Oliver N. wrote:

Ahh, yes, that’s another long-standing issue. I’m not sure we’ve even
come up with a good workaround for it, since there’s no good way to work
around Ruby’s need to invoke “initialize” on construction. Hmmm.

I’d be inclined to use a keyword like attr_constructor to tell jruby (or
any other ruby) to explicitly override the default naming:

def MyClass < SomeJavaClass
attr_constructor :the_actual_ruby_constructor

def the_actual_ruby_constructor

end

def initialize
# now an overridden java method
end
end

end
# called for construction instead of initialize…

I suspect this is a still-open issue where calling abstract methods

-john c.

  • Charlie


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I would vote for the first suggestion by Charlie:
initialize (in line with id and send for example)

because this is more a more Ruby-like syntax (since this is on the Ruby
side).

Cheers,
Chiaming H.

----- Original Message ----
From: john casu [email protected]
To: [email protected]
Sent: Monday, November 3, 2008 8:26:15 PM
Subject: Re: [jruby-user] Java inheritance question…

Charles Oliver N. wrote:

Ahh, yes, that’s another long-standing issue. I’m not sure we’ve even come up with a good workaround for it, since there’s no good way to work around Ruby’s need to invoke “initialize” on construction. Hmmm.

I’d be inclined to use a keyword like attr_constructor to tell jruby (or
any other ruby) to explicitly override the default naming:

def MyClass < SomeJavaClass
attr_constructor :the_actual_ruby_constructor

def the_actual_ruby_constructor

end

def initialize
# now an overridden java method
end
end

# works as method impl for initialize from superclass

processStimulus is an abstract function inherited from the Java class, which in this case (and this is the entire point of this exercise) is implemented in Jruby.

gui/gui_display.rb:40:in `initialize’: invokee not a java object (TypeError)

Charlie,
Charles Oliver N. wrote:

  • Charlie


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Ahh, yes, that’s another long-standing issue. I’m not sure we’ve even
come up with a good workaround for it, since there’s no good way to work
around Ruby’s need to invoke “initialize” on construction. Hmmm.

So we’re probably into new territory here. One idea I’d had for fixing
the “initialize” conflict would be to allow using a different name for
the initialization method on a Ruby subclass of a Java type. A couple
ideas:

initialize (in line with id and send for example):

class MyClass < SomeJavaClass
def initialize
# called for construction instead of initialize
end

def initialize
# works as method impl for initialize from superclass
end
end

ClassName (like a Java constructor):

class MyClass < SomeJavaClass
def MyClass
# called for construction instead of initialize…
end

I’m looking for input on this. If we come up with something reasonable,
we can look to push it in 1.1.6, which we want to flip pretty soon.

  • Charlie

john casu wrote:

Ruby initializer; but abstract methods it implements will not be
which in this case (and this is the entire point of this exercise) is

This is still broken in today’s 1.1.5 release, but I’m getting a
thanks,

thanks for your help,

I’m doing some work with Java3D 1.5.3/JRuby 1.1.4, and I’m trying
end
security settings allow it.


http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Matt B. wrote:

Or, how about a keyword, like alias, that maps the Java (abstract or
not) method name to a ruby method impl?

def MyClass < SomeJavaClass
java_method_override initialize java_initialize
java_method_override baseClassMethodName ruby_method_name

This is probably worth adding as well as initialize which still
seems the most Ruby-like solution to the more common problem of mapping
constructors. It’s a little wordy though.

First, it would have to be symbols; “alias” is a keyword and as such can
take non-symbols, but this would not be a keyword.

Second…maybe just java_override? java_alias? java_alias might raise
the expectation that it’s going to create a method rather than just
tag one as being associate with a particular Java name.

So maybe…

def MyClass < SomeJavaClass
java_override :initialize => :java_initialize
or
java_method :initialize => :java_initialize
or
bind_java :java_initialize => :initialize

Hmm.

FWIW, this is a valid discussion even with initialize present, since
there’s a few other methods we don’t allow you to implement (id,
send, and others).

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Charles Oliver N. wrote:

(or any other ruby) to explicitly override the default naming:
constructors. It’s a little wordy though.
def MyClass < SomeJavaClass
send, and others).

I wasn’t sure if initialize was the only method one has to watch out
for. I’d also point out that jruby isn’t the only ruby built on the
back of another languages’ runtime. macruby comes to mind.

I’d be in favor of a solution that was explicit, wrt overriding
initialize, etc… and one that could be used as the basis for a generic
mechanism for solving the problem.

Are there other cross-language constructs, such as interrupts, for
example, that behave differently or don’t quite map exactly, in Java and
Jruby ?? How would one handle those ?

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

john casu wrote:

Charles Oliver N. wrote:

Ahh, yes, that’s another long-standing issue. I’m not sure we’ve even
come up with a good workaround for it, since there’s no good way to
work around Ruby’s need to invoke “initialize” on construction. Hmmm.

I’d be inclined to use a keyword like attr_constructor to tell jruby (or
any other ruby) to explicitly override the default naming:

Or, how about a keyword, like alias, that maps the Java (abstract or
not) method name to a ruby method impl?

def MyClass < SomeJavaClass
java_method_override initialize java_initialize
java_method_override baseClassMethodName ruby_method_name

def java_initialize
puts “implemented the ‘interface’ method.”
end

def ruby_method_name
base_res = super
puts “added some stuff to #{base_res}”
base_res
end
end


Matt


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

john casu wrote:

I wasn’t sure if initialize was the only method one has to watch out
for. I’d also point out that jruby isn’t the only ruby built on the
back of another languages’ runtime. macruby comes to mind.

Actually that’s a good idea, Laurent might have similar issues to deal
with integrating into ObjC type hierarchies. We should talk to him.

I’d be in favor of a solution that was explicit, wrt overriding
initialize, etc… and one that could be used as the basis for a generic
mechanism for solving the problem.

I agree. In general it seems like putting control in the hands of the
user is better than trying to get at the “best” magic.

Are there other cross-language constructs, such as interrupts, for
example, that behave differently or don’t quite map exactly, in Java and
Jruby ?? How would one handle those ?

As in a thread interrupt? For the most part we just try to implement
blocking operations to be interruptible in JRuby. In general, Ruby has a
lot more ways to interrupt things than Java does, so most of those cases
come along for the ride.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Charles Oliver N. wrote:

generic mechanism for solving the problem.
lot more ways to interrupt things than Java does, so most of those cases
come along for the ride.

ooops… brain freeze… I meant exceptions…

What I’m thinking of are cases, as in the constructor, where the mapping
between jruby & java isn’t exact. In this case, an exception raised
in a Java routine might not be caught by the right rescue clause in a
jruby exception block, and vice versa.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email