I agree, any attempt at improvement wouldn't be general. thanks for
the explanation.
On Thu, Dec 6, 2018 at 10:45 AM Dawid Weiss wrote:
>
> I don't think it makes much sense, to be honest. Without actual
> reflection you're binding things to a particular implementation
> (you're assuming this and
I don't think it makes much sense, to be honest. Without actual
reflection you're binding things to a particular implementation
(you're assuming this and that JDK implementation). That's why we
decided to remove it instead of making it overly complex (and possibly
untrue). If a test is using it, pe
That's what it looked like to me, too. I wonder if it would be worth
improving the estimate for some very common Collections classes? I see
this comment eg in BaseIndexFileFormatTestCase:
// we have no way to estimate the size of these things in codecs although
// something like a Coll
I just started doing that and noticed that in "close"'s documentation it
says:
NOTE: You must ensure no other threads are still making changes at the
same time that this method is invoked.
Which I guess is what I've missed and should be enough. Thanks for the
support! :)
On 12/5/18 12:52 PM, Mi
> It's entirely possible it fails to dig into Maps correctly with newer Java
> releases; maybe Dawid or Uwe would know?
We have removed all reflection from that class a while ago exactly
because of encapsulation issues introduced in newer Java versions.
https://github.com/apache/lucene-solr/blob/
I think you mean RamUsageEstimator (in Lucene's test-framework)?
It's entirely possible it fails to dig into Maps correctly with newer Java
releases; maybe Dawid or Uwe would know?
Mike McCandless
http://blog.mikemccandless.com
On Tue, Dec 4, 2018 at 12:18 PM Michael Sokolov wrote:
> Hi, I'm
