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
> 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/
ote:
> Hi, I'm using RamUsageCrawler to size some things, and I find it seems
> to underestimate the size of Map (eg HashMap and ConcurrentHashMap).
> This is using a Java 10 runtime, with code compiled to Java 8. I
> looked at the implementation and it seems as if for JRE classes,
Hi, I'm using RamUsageCrawler to size some things, and I find it seems
to underestimate the size of Map (eg HashMap and ConcurrentHashMap).
This is using a Java 10 runtime, with code compiled to Java 8. I
looked at the implementation and it seems as if for JRE classes, when
JRE >= 9, w
