On 25 September 2017 at 13:31, Gunnar Morling wrote:
>
> My question would be why do you need the inheritance to begin with? You could
> just invoke the methods on the logger interface defining them. It'll require
> you to have two (or more) fields for the logger references, but then you'll
> g
Generally speaking, generating one instance of something versus generating
N is better. It has the potential to affect performance in regards to
memory consumption in relation to the size of N
On Mon, Sep 25, 2017 at 7:12 AM Sanne Grinovero wrote:
> On 25 September 2017 at 12:47, Steve Ebersol
My question would be why do you need the inheritance to begin with? You
could just invoke the methods on the logger interface defining them. It'll
require you to have two (or more) fields for the logger references, but
then you'll get just a set of more related and coherent methods offered
from eac
On 25 September 2017 at 13:09, Gunnar Morling wrote:
> 2017-09-25 13:47 GMT+02:00 Steve Ebersole :
>>
>> I'm missing something. IIUC the discovery was that, e.g., having
>> something
>> like `BaseHibernateSearchLogger` in module-A and then something like
>> `RealLogger` in module-B that extends `
On 25 September 2017 at 12:47, Steve Ebersole wrote:
> I'm missing something. IIUC the discovery was that, e.g., having something
> like `BaseHibernateSearchLogger` in module-A and then something like
> `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes
> extra space to be t
2017-09-25 13:47 GMT+02:00 Steve Ebersole :
> I'm missing something. IIUC the discovery was that, e.g., having something
> like `BaseHibernateSearchLogger` in module-A and then something like
> `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes
> extra space to be taken up w
I'm missing something. IIUC the discovery was that, e.g., having something
like `BaseHibernateSearchLogger` in module-A and then something like
`RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes
extra space to be taken up within the VM memory space. Yet this is still
exactly
Our friend and colleague Andrew Dinn from the OpenJDK team is working
on a series of blog posts to help people understand the impact of
certain design choices on the cost of internal JVM metadata and native
memory; this affects bootstrap costs of both the JVM and our
libraries, overhead at runtime
