<headius[m]>
bit of configuration tweaks there we can consider updating for 9.3
<headius[m]>
actually we can get familiar with and discuss all of this, but taking over the official jruby image seems like just a matter of updating this repo to point at our new location and a contact email
<enebo[m]>
If it just a rake task to make it or something pretty simple but yeah we need to understand how transfer works
<headius[m]>
I have asked on cpuguy83's issue for clarification that I am understanding the steps
<headius[m]>
well it is a PR so it could be a rake task
<headius[m]>
he may have an automated way to update that official-images file, I am not sure
<headius[m]>
enebo: maybe we should make a jruby.org email for this maintainer email?
<headius[m]>
I can't find guidelines on what email should be used, like do they require it to go to one person or something
<headius[m]>
but docker@jruby.org would seem appropriate
<enebo[m]>
admin
<enebo[m]>
Then we don't need to make one
<headius[m]>
admin is fine with me if it is fine with you
<headius[m]>
I assume at least you and I are on that
<enebo[m]>
yeah it is one less thing to have to have credentials for
<enebo[m]>
we should both get email from it
<headius[m]>
ok
<enebo[m]>
just confirmed both of us get email from there forwarded
<headius[m]>
ok
<headius[m]>
this email should be ok
<headius[m]>
Maintainers: Amazon Corretto Team <corretto-team@amazon.com> (@corretto)
<headius[m]>
Corretto also has individuals in there
<headius[m]>
but I will go with just the admin address now and see if that is ok
<headius[m]>
what name should I give that address?
<headius[m]>
JRuby Admin?
<enebo[m]>
sure
<byteit101[m]>
headius: Do you think it's likely you'll have time to review my Q's on concrete new before 9.3? I'd love to finish this before Christmas next week
<headius[m]>
yeah it is in my queue but I have been taking care of some long overdue tasks this week
<headius[m]>
I can look it over in a bit... the docker takeover wasn't as involved as I expected
<byteit101[m]>
I figured, don't want to nag too much!
<headius[m]>
no worries!
<headius[m]>
enebo: two commits that will be done for each JRuby release...
<headius[m]>
9.2.14.0 docker update should be available soon, and transfer to jruby team/repo is in progress
<headius[m]>
enebo: once the transfer has happened I will post something to mailing list and social medias
<enebo[m]>
ok
<headius[m]>
fidothe: we are around whenever to chat about automating future docker updates... no releases coming up until after the new year so we have time
<headius[m]>
enebo: fidothe added a comment on the transfer issue with some links to automation stuff... we can look into that to make it simple
<headius[m]>
byteit101: I am a little confused by the jallocate related questions
<byteit101[m]>
To be fair, I probably left out some details on most of them :-)
<byteit101[m]>
#new -> call java ctor & ruby initialize, as normal
<headius[m]>
How should I set allocators, the new method, and initialize? new seems to be magical on ConcreteJavaProxy instances, and the way I do it seems very heavy.
<headius[m]>
I created __jallocate!, different from initialize and __jcreate! in that it doesn't call any ruby methods. I'm unsure how to get __jcreate! to not call initialize
<headius[m]>
right
<byteit101[m]>
however, if someone wants to create a custom initialization step (see jrubyfx :-) ), then they override new, and have to call the java ctor somehow without calling any init methods
<byteit101[m]>
Part of that question is about that, and the other part is how to install the correct methods on the class/object
<headius[m]>
so if you wanted to override you would have to call `jallocate!` yourself?
<headius[m]>
right so this is about the complexities of the allocate+initialize cycle not really matching what we do for the Java part
<byteit101[m]>
Yes, whereas previously you called initialize, and it does java creation too, however I was unable to figure out how to install such a mechanism
<byteit101[m]>
No, this is about how I don't know how to munge the RubyClass methods to be straightfoward
<byteit101[m]>
see files:
<headius[m]>
ok
<headius[m]>
I am thinking we kill `allocate` since that path won't work right (can't allocate the Java object properly without initialize args)
<headius[m]>
your overwrite isn't unreasonable... why do you feel it is wrong?
<byteit101[m]>
The instanceof
<headius[m]>
oh I see
<byteit101[m]>
and the fact that those lookups are cached and no longer dynamic
<byteit101[m]>
and overwriting the method removes the java aspect
<headius[m]>
so if it is an IR method you know it was defined in Ruby
<headius[m]>
what happens to oldNewMethod in that case?
<headius[m]>
bear with me... you overwriteInitialize in that case because there was nonstandard logic for `new`, yes?
<byteit101[m]>
correct, the ensuring that it's reified
<headius[m]>
but you have already overwritten the nonstandard `new` by this point
<headius[m]>
and custom `new` doesn't necessarily mean custom `initialize` which is what the overwriteInitialize handles... so I think I am missing something
<headius[m]>
i.e. if new is an IRMethod you replace it and then capture the original initialize for StaticJCreateMethod
<headius[m]>
but the original IRMethod `new` still gets wiped out by your `new`
<headius[m]>
so I am missing what the IRMethod check is really accomplishing I think
<byteit101[m]>
this logic is called from become_java!, btw
<byteit101[m]>
When we become java, I try to update new to be the java init sequence. If someone overrode new, don't overwrite it
<byteit101[m]>
class A < JavaClz; def new; x = allocate; x.<make-java>(); x; end; def initialize; puts "not in ctor :-O"; end; end;
<byteit101[m]>
Previously, <make-java> was `class.superclass.method(:initialize).bind(self).call`
<byteit101[m]>
I wasn't sure how to capture that in my new changes
<headius[m]>
aha ok
<headius[m]>
but it does overwrite `new` does it not?
<headius[m]>
am I reading it wrong?
<byteit101[m]>
the class A does, then A.become_java! doesn't overwrite new
<byteit101[m]>
(see JavaProxyClass:551 for the "new" override)
<headius[m]>
ok
<byteit101[m]>
If you don't call become_java!, then `NewMethod` is called, which does it for you, then delegates to `newMethodReified`. See line ConcreteJavaProxy:439 for that install
<byteit101[m]>
Which isn't called for each class, just the parent proxy
<headius[m]>
ok
<headius[m]>
sorry I flipped the logic in my head
<byteit101[m]>
I should make a diagram for you now
<headius[m]>
you overwrite new if NOT IRMethod
<headius[m]>
yeah a diagram would help... I understand now