it was really meant to be ~ internal, aj guess 😉 ... for jrubyc only. anyway JRuby can work around that.

@enebo we probably only want this for 9.2 or do you have a string preference for getting this into 9.1.13?

OK so its part of JRuby's core extension API ... it can not be simply removed in another release.
... we can start deprecating subclasses (in favor of each_object(klass)) as this seems to be an issue.
so you will need to either not require 'jruby/core_ext' or simply undef the Class#subclasses method def.

@kares yeah I think part of the solution will be to deprecate on our side and replace it with something which does not conflict. Since we have been exposing this as a public method for many years (since at least 2011?) now this is unfortunate. I am always amazed how long it takes for someone to notice these issues but perhaps AS + jrubyc is uncommon?

@kares oh we should get each_object usage into 9.1.13.0 internally and not use subclasses. At that point people can include jruby/core_ext before AS is loaded and have AS win while not making anything on our side stop working. So if you plan on changing our internal consumer(s) then please cp that commit to jruby-9.1.13.0 branch.

@enebo I was wrong, JRuby is actually not using subclasses internally. it was meant to be user consumed.
the problem I guess is that JRuby's version returns smt completely unexpected for the AR::Base case ((when jruby/core_ext is loaded after AS boots), guess its missing logic to exclude some noise (otherwise it seems to be doing fine) :

jruby-1.7.26 :021 > ActiveRecord::Base.subclasses.first
 => #<ActiveRecord::AttributeMethods::GeneratedAttributeMethods:0x390e814c>

... which are just generated (included) modules - should be fine to get them excluded although not 100% sure

In fact, it includes only the generated modules - they are 1:1 with all the subclasses of ActiveRecord::Base in my use case and the generated modules don't have 'subclasses' defined anymore after jruby/core_ext is loaded after AS is up. We're working around this by not using 'subclasses' but rather implementing our own as active record is coming in very early and jruby/core_ext is only in one of our modules. For example, in the test case I put in, there is only one subclass returned - the generated module and it's missing table_name.

the underlying issue is that we return the raw subclasses collection that a RubyClass manages internally.
that includes include/prepend wrappers (which are not really useful for the user) are included - gets messy.

ObjectSpace does filter these out so my proposal would be to simply re-implement JRuby's subclasses using OS for 9.1.13 ... if someone needs the old way there's still a way using klass.to_java.subclases.
... expecting this would mean full compatibility with AR::Base returned sub-classes

for 9.2 JRuby might deprecate Class#subclasses altogether (provide a non core-ext polluting alternative).

@enebo willl be back-porting the patch to 9.1.13 (will change the target after its done) to make JRuby's subclasses behave as expected - its re-implemented using ObjectSpace (which filters out the internal module wrappers) so it should work fine with AS/Rails. on 9.2 the method should likely get deprecated.

landed as 916b1e1

I need to point out that this new subclasses impl will be much slower than the built-in version due to the cost of running the each_object block. That may or may not matter for typical uses.

Under the covers, each_object for a class just does what the old subclasses did, but the Ruby code could be more efficient.

Has this been backported to 9.1 branch yet?

yep, backported.
we need to to the ObjectSpace walking since subclasses needs to skip wrappers -> which might be hiding the real subclass of a class (as it stands in between).