I would recommend people to use a persistent collection library like Vavr instead (many other options too).
It provides the same functionality but without string field references (a disaster for refactoring). Additionally it won't require learning a new DSL for basic comparisons because the logic is contained in normal Java code with lambdas and method references.
Fair enough, what's the performance hit of reflection like for larger collection sizes? is this library intended for exploring data during development or a production system?
I haven't done performance benchmarking, nor tuned it yet. That's my next plan. The library is largely meant for firing ad-hoc queries in production, or for tweaking data-sets and database queries.
Though reflection is slower, it allows us to fire queries on List<Object> sort of collections and the built in type conversions may allow us to compare a Calendar instance to a Date, or a Long to a String (with implicit parsing and conversions).
I ran some performance tests and added a basic caching layer on reflection - that improved it by around 50% in the very basic of tests. You may look at the results in README at https://github.com/sangupta/gather repo.
8 comments
[ 1.9 ms ] story [ 31.5 ms ] threadIt provides the same functionality but without string field references (a disaster for refactoring). Additionally it won't require learning a new DSL for basic comparisons because the logic is contained in normal Java code with lambdas and method references.
this:
becomes this:Though reflection is slower, it allows us to fire queries on List<Object> sort of collections and the built in type conversions may allow us to compare a Calendar instance to a Date, or a Long to a String (with implicit parsing and conversions).