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

Internal limitation or big code-18? #65

Closed
sberthiaume opened this issue Apr 21, 2015 · 3 comments
Closed

Internal limitation or big code-18? #65

sberthiaume opened this issue Apr 21, 2015 · 3 comments

Comments

@sberthiaume
Copy link

Not sure if I'm doing something wrong of of there is some kind of technical limitation to what Reflections can do, I get very weird results when using the API; I have an Interface, TO that extends Serializable (and does nothing else, no extra methods, nothing), but when I scan for Serializable, I don't seem to get all the TOs, far from it:

Reflections reflections = new Reflections("my.project.pkg2", new SubTypesScanner(false));
Set<Class<? extends Serializable>> serializables = reflections.getSubTypesOf(Serializable.class); //676 classes
Set<Class<? extends TO>> TOs = reflections.getSubTypesOf(my.project.pkg1.TO.class); //446 classes
Collection intersec = CollectionUtils.intersection(serializables, TOs); //8 classes WTF!!!

TO is actually in another package than the one I'm scanning and the project is quite large. Using (old) Java 6 on Windows if it matters; and yes I tried to do the intersection manually to make sure the Apache Commons lib didn't contain a bug.

Bug, limit, code-18, what is happening here?

@sberthiaume sberthiaume changed the title Internal limitation or big code-18^ Internal limitation or big code-18? Apr 21, 2015
@sberthiaume
Copy link
Author

Additional info it it matters: if I scan for Object.class I get ~6510 classes and all my 446 TOs are in there. Could the issue be with Interfaces and/or Serializable itself?

@ronmamo
Copy link
Owner

ronmamo commented Apr 22, 2015

This is a familiar behavior, still, not well understood and might be a code-18 - let me know what you think:
Given MyModule extends AbstractModule implements Module - and only MyModule is scanned, then Reflections stores only the inverted supertype (AbstractModule has childlren MyModule), but does not for (Module has children AbstractModule).
The effect is that when querying for subtypes of Module nothing returned (its direct children were not scanned), but querying for subtypes of AbstactModule returns the expected result (its direct children were scanned).

There's a missing link from Module to AbstractModule, and this breaks transitivity.

The reasons/solutions might vary:

  • Scan all the transitivelly relevant jars a priori. This is the preffered naive solution. Cons - too long scan and too big and mostly irrelevant store.
  • Expand relevant supertypes a posteriori. See example. That is, link Module and AbstractModule in the store.
  • Rethink modularity, model and meta model. Have the meta model encapsulated in a common module, that is scanned. Query the model based on its meta model, and not the implied type. Call it by its name.

@sberthiaume
Copy link
Author

Ok, so any parent class of a class outside of the scanning scope might not be know to Reflection; if I find time I will try to test this with a small scale experiment.

Could be a good idea to document that behavior in the javadoc for getSubTypesOf(). Could also be a nice additional option for SubTypesScanner; letting it scan everything, but only use the package as a way to filter out the final results. For us, performance isn't that big of a deal right now since we use Reflection mainly for system-wide "integration" testing (we scan for common mistakes).

I will try scanning the wider "my.project", but post-filter-out results that aren't in the package I want to scan to see if indeed it would be a viable workaround.

@ronmamo ronmamo closed this as completed May 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants