<headius[m]>
That java_class leads into a deprecated API you may not want to mess with. So you wanted to get the Java class from an unbound method?
<headius[m]>
boc_tothefuture: the best way to do that might be to get the Java class object which I think you can do by calling two Java on the Ruby version that we set up, and then just using the Java reflection methods
<headius[m]>
Ugh calling to_java
<headius[m]>
I'm not at my computer right now but I'll be back in a while
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us_ has joined #jruby
<boc_tothefuture[>
sure no worries.. not sure I am following you. When I call to_java on the "ruby" method object I don't seem to be able to access annotations.
<boc_tothefuture[>
But what I am trying to get is both `foo_bar` and `fooBar` and the fact they both have that annotation.
ur5us has joined #jruby
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 264 seconds]
_whitelogger has joined #jruby
codeponpon[m] has joined #jruby
ur5us has joined #jruby
chrisseaton[m] has quit [Quit: Idle for 30+ days]
ur5us has quit [Ping timeout: 260 seconds]
<boc_tothefuture[>
Following up, what I would like to do is: `foo.methods.some_magical_call_that_gets_me_the_java_method_object.annotation_present?` but I can't figure out that method call
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
kai[m] has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
ravicious[m] has quit [Quit: Bridge terminating on SIGTERM]
CharlesOliverNut has quit [Quit: Bridge terminating on SIGTERM]
MarcinMielyskiGi has quit [Quit: Bridge terminating on SIGTERM]
liamwhiteGitter[ has quit [Quit: Bridge terminating on SIGTERM]
ChrisSeatonGitte has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m] has quit [Quit: Bridge terminating on SIGTERM]
OlleJonssonGitte has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
XavierNoriaGitte has quit [Quit: Bridge terminating on SIGTERM]
slonopotamus[m] has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
boc_tothefuture[ has quit [Quit: Bridge terminating on SIGTERM]
hopewise[m] has quit [Quit: Bridge terminating on SIGTERM]
headius[m] has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
codeponpon[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
nhh[m] has quit [Quit: Bridge terminating on SIGTERM]
kroth_lookout[m] has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
KarolBucekGitter has quit [Quit: Bridge terminating on SIGTERM]
daveg_lookout[m] has quit [Quit: Bridge terminating on SIGTERM]
RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
rdubya[m] has quit [Quit: Bridge terminating on SIGTERM]
JesseChavezGitte has quit [Quit: Bridge terminating on SIGTERM]
FlorianDoubletGi has quit [Quit: Bridge terminating on SIGTERM]
GGibson[m] has quit [Quit: Bridge terminating on SIGTERM]
MattPattersonGit has quit [Quit: Bridge terminating on SIGTERM]
dentarg[m] has quit [Quit: Bridge terminating on SIGTERM]
kai[m] has joined #jruby
ruurd has joined #jruby
enebo[m] has joined #jruby
lopex[m] has joined #jruby
headius[m] has joined #jruby
MattPattersonGit has joined #jruby
rdubya[m] has joined #jruby
GGibson[m] has joined #jruby
hopewise[m] has joined #jruby
JesseChavezGitte has joined #jruby
nhh[m] has joined #jruby
daveg_lookout[m] has joined #jruby
KarolBucekGitter has joined #jruby
RomainManni-Buca has joined #jruby
ahorek[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
TimGitter[m] has joined #jruby
byteit101[m] has joined #jruby
ravicious[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
boc_tothefuture[ has joined #jruby
CharlesOliverNut has joined #jruby
ChrisSeatonGitte has joined #jruby
TimGitter[m]1 has joined #jruby
kares[m] has joined #jruby
OlleJonssonGitte has joined #jruby
slonopotamus[m] has joined #jruby
JulesIvanicGitte has joined #jruby
UweKuboschGitter has joined #jruby
BlaneDabneyGitte has joined #jruby
FlorianDoubletGi has joined #jruby
dentarg[m] has joined #jruby
codeponpon[m] has joined #jruby
XavierNoriaGitte has joined #jruby
kroth_lookout[m] has joined #jruby
<daveg_lookout[m]>
headius: 9.2.15.0.SNAPSHOT with your fiber fix is looking good so far, 12 hours in. No instances have died, GC is much more stable. It'll take at least a week to really be confident, but promising. Thank you again!
<headius[m]>
daveg_lookout: I will cautiously take that as good news
<boc_tothefuture[>
headius: No rush, but wanted to make sure you saw my updates above?
<headius[m]>
I'll have a look after my tea is ready 😀
<headius[m]>
boc_tothefuture: ok so what you want isn't really there in a direct form
<headius[m]>
the information is there and can be dug out but not through any of the direct mechanisms (i.e. you can get this info through java_class but it is an unsupported API that predates the class proxy system)
<headius[m]>
this would not be a bad idea for an addition to the API though... like have methods derived from a Java class be some descendant of Method or UnboundMethod that provides additional metadata about the Java methods
<headius[m]>
so about the foo_bar and getting from that method to the Java method
<headius[m]>
looking at the related classes
<headius[m]>
yeah this is a bit trickier
<boc_tothefuture[>
Yeah, or even if just .to_java on the ruby method existed and returned the Java method object on those derived from java classes would work.
<headius[m]>
that is a possibility but it is complicated by the fact that we often have to aggregate multiple methods in a given Ruby name due to overloads
<headius[m]>
there's no way to access all the methods that we aggregate... a bit of an oversight or good encapsulation depending on how you look at it
<headius[m]>
So what do we really want? Exposing the list of aggregated methods would be simple enough
<boc_tothefuture[>
Well, I need to be able to map those back to a java method so i can check the annotation.
<boc_tothefuture[>
or alternatively, regenerate them from the java method.
<headius[m]>
right
<headius[m]>
I think going from the Ruby side to the Java methods it aggregates would be the best way
<headius[m]>
exposing just the methods would not be a difficult addition
<headius[m]>
exposing how we select those methods when you call with various types... that is a little trickier
<headius[m]>
I mean it is possible to get the methods now but not through any public API
<headius[m]>
enebo: what do you think of an enhanced Method/UnboundMethod API for Java proxy methods?
<headius[m]>
to basically provide a way to get at the Java method objects and metadata
<enebo[m]>
headius: I think there seems to be cases where people want to write java <-> java calls using a Ruby syntax without any boxing
<enebo[m]>
So I can see a use-case for it
<enebo[m]>
I wonder if we should write it as external library to figure out API and then deeply integrate once we come up with what we like
<enebo[m]>
So it may not be initially quick or maybe it still will be but we won't commit on the API until we have had some people use it
<headius[m]>
boc_tothefuture: seems like in this case you are doing some additional metaprogramming that needs to be advised by the Java metadata yeah?
<enebo[m]>
Ah like coercion of some arguments
<headius[m]>
yeah in this case boc_tothefuture wants to be able to see if the java methods have a particular annotation
<headius[m]>
so it is purely metadata that would be there through reflection
<enebo[m]>
I mean my example above is just a single case where we would want no coercion of any arguments
<enebo[m]>
Perhaps breaking this part to reflection and invocation as separate pieces
<headius[m]>
this ties in with kares PR to add all the reflective support methods to java.lang.reflect.Method and friends so we can ditch java_class
<enebo[m]>
but combining the two seems like the deep integration bit since you do not want to pay the ruby execution price
<headius[m]>
so like if java_obj.method(:foo) returned a subclass of Method like JVMMethod that provided a .all_methods list or something, those would just be java.lang.reflect.Method objects
<headius[m]>
basically just exposing the reflection aggregation we already do
<enebo[m]>
So any methods which are on Ruby would still be the Ruby versions but we would have others?
<enebo[m]>
My only reservation there is that Ruby sometimes adds new methods to classes
<enebo[m]>
Maybe not a huge concern for Method?
<headius[m]>
it would still extend Method
<headius[m]>
unless you use the extra methods or expect it to .class == Method you would never notice our version
<headius[m]>
it would just add some additional methods for accessing the reflected JVM bits
<enebo[m]>
yeah my point is any extra methods we add cannot conflict with any methods MRI adds later to Method
<enebo[m]>
java_obj.java_method(:foo) might be more future proof for example
<enebo[m]>
Or maybe even Java.method(java_obj.method(:foo))
<headius[m]>
I am reluctant to add more special methods to the proxied Java objects for the same reason
<headius[m]>
getJavaMethod would be inaccessible on some Java type
<headius[m]>
ah well there is an argument to be made for some mirror-like API you have to apply to the objects
<enebo[m]>
so that second one could work and never run into compat issues
<headius[m]>
I think namespace pollution was one justification for using an external mirror API
<enebo[m]>
but I guess I would like to see some consumption code too
<headius[m]>
it is a bigger pill to swallow, though, design wise
<headius[m]>
obj.method.jvm_methods is pretty simple
<headius[m]>
obj.method(:foo).jvm_methods rather
<enebo[m]>
I think method would still return at java level a subtyped object but until you accessed through mirror you would not see the methods
<enebo[m]>
That is fine
<enebo[m]>
I mean my concern was largely we cannot just add 'attributes' or 'signatures' onto Method because MRI is the shark which never stops swimming
<headius[m]>
ah no I don't want to do that exactly
<enebo[m]>
I do not see jvm_methods being taken by MRI
<headius[m]>
and we can't because one Ruby method might aggregate multiple JVM methods
<enebo[m]>
yeah so my Java.methods(ruby_method_obj) might make more sense
<enebo[m]>
but there are multiple paths to this
<enebo[m]>
In Ruby all arities is one method (today unless pattern matching gets added to def)
<enebo[m]>
So asking for all same-named versions in Java makes sense from a Ruby method perspective
<enebo[m]>
but it is one to many
<enebo[m]>
Or do you mean multiple types and multiple versions of the same named method?
<headius[m]>
well I just mean if you get the Ruby Method object for what would be one of our proxied Java types, you would have a way to access all JVM methods that support it
<headius[m]>
mostly this is a path from Ruby reflective objects to JVM reflective objects
<headius[m]>
not a lot of new API other than opening up some guts
<headius[m]>
basically like .java_class was intended to toss you over to the JVM reflective structures
<headius[m]>
(except that it made a new abstraction rather than just giving you the java.lang.Class object, and that is what kares is improving)
<headius[m]>
I mean I look at this like what if it were all still implemented in Ruby... a proxied class would have to implement its own .method to return the special "invoker" methods we use to wrap all overloads of a given name
<enebo[m]>
sure I can see that
enebo has joined #jruby
<headius[m]>
enebo: daveg_lookout I have moved the enum peek issue to 9.2.15.0 since it appears we have a reasonable diagnosis and "good enough" treatment for the problem
<enebo[m]>
headius: ok
<daveg_lookout[m]>
Sounds good to me.
enebo has left #jruby [#jruby]
<Freaky>
headius[m]: just seen that JSON parse issue with a record fetched from Redis
<Freaky>
didn't get a backtrace from there unfortunately
<headius[m]>
drat
<headius[m]>
same error?
<Freaky>
yup
<headius[m]>
recommendation stands I guess... we need more information either from that backtrace option or by adding some logging to the place where it fails
<headius[m]>
I have no explanation 😭
subbu is now known as subbu|lunch
<Freaky>
it only happens when I'm not trying to reproduce it
<headius[m]>
Freaky: you could try reporting it to elasticsearch folks, maybe they have seen it before
<Freaky>
thrown thousands of commits at it, sequentially and in parallel, nothing
subbu|lunch is now known as subbu
<Freaky>
er, requests
<headius[m]>
yeah that is frustrating
<Freaky>
will leave it for now, should have more information to go on next time it crops up
<Freaky>
someone on stackoverflow mentioned they got similar errors which turned out to be a BOM, but it doesn't seem this would just appear and disappear
<Freaky>
I do have UseStringDeduplication enabled, but that only kicks in on full GC runs I think?
<headius[m]>
yeah I wouldn't expect this to be intermittent but that is an interesting cause
<headius[m]>
is that an elasticsearch setting?
<Freaky>
JVM option
<headius[m]>
ahh shouldn't affect us, we don't use JVM strings for most stuff
<Freaky>
G1GC thing
ur5us has joined #jruby
ur5us_ has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
<Freaky>
another thing I've noticed is JBDC seems quite slow, spending 10x longer getting results into the Ruby side than Sequel's logged query time
<Freaky>
bit annoying a query taking 2 milliseconds but burning 30 to get it into something I can use
<Freaky>
the C driver has some optimization for that, think you maintained a port of it years ago
<Freaky>
JDBC, close enough
<jeremyevans>
Freaky: Sequel log only reports execution time, not time to convert result set into Ruby. That's because conversion of result set happens during iteration, and arbitrary user code can happen during iteration (true for all Sequel adapters I think).
<Freaky>
jeremyevans: I wonder if there's some low-hanging fruit for bits that could be done better in Java
<Freaky>
like parse_pg_array
<jeremyevans>
Freaky: Probably. I'm not a Java programmer, but you could probably have something like sequel_pg for Java.