Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: Generics and downcasts Date: Tue, 25 Apr 2017 19:53:09 -0400 Organization: Aioe.org NNTP Server Lines: 59 Message-ID: References: NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:36535 On 4/25/2017 4:40 PM, Marcel Mueller wrote: > On 25.04.17 22.20, Arne Vajhøj wrote: >> .NET got generics relative early in its history, so MS decided >> that compatibility with old collection classes was not that important. >> Java was in a different situation, so type erasure and collection >> compatibility was chosen. And we have to live with it. > > The bad news is that although this breaking change they did not manage > to give their new container classes a consistent interface. There are at > least 4 distinct and fully equivalent implementation of the Count > property. And methods with the same name (like Add) have significantly > different semantics in different container types. > >>> There are other pitfalls that are by far more expensive. >>> E.g. if you miss to declare a trivial Java method as final. This >>> prevents the JIT from inlining the method body. This may add an overhead >>> of an order of magnitude or even more. >> >> I think this is a myth. >> >> https://www.ibm.com/developerworks/library/j-jtp1029/ (Brian Goetz 2002) >> >> >> Like many myths about Java performance, the erroneous belief that >> declaring classes or methods as final results in better performance is >> widely held but rarely examined. The argument goes that declaring a >> method or class as final means that the compiler can inline method calls >> more aggressively, because it knows that at run time this is definitely >> the version of the method that's going to be called. But this is simply >> not true. Just because class X is compiled against final class Y doesn't >> mean that the same version of class Y will be loaded at run time. So the >> compiler cannot inline such cross-class method calls safely, final or >> not. Only if a method is private can the compiler inline it freely, and >> in that case, the final keyword would be redundant. >> > > I never said that the Java compiler might inline such function calls. > This is up to the JIT. Well - next section covers that more explicit. On the other hand, the run-time environment and JIT compiler have more information about what classes are actually loaded, and can make much better optimization decisions than the compiler can. If the run-time environment knows that no classes are loaded that extend Y, then it can safely inline calls to methods of Y, regardless of whether Y is final (as long as it can invalidate such JIT-compiled code if a subclass of Y is later loaded). So the reality is that while final might be a useful hint to a dumb run-time optimizer that doesn't perform any global dependency analysis, its use doesn't actually enable very many compile-time optimizations, and is not needed by a smart JIT to perform run-time optimizations. Arne