commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [All] Compiler Warnings/What's left for a release? [WAS: [Poo l] C ompiler Warnings/What's left for a release?]
Date Thu, 24 Apr 2003 14:40:34 GMT
The way I read it is that the byte code generated must reflect this scheme
in order to implement and comply with the spec, the special methods are
generated and called. How a JVM optimizes byte codes is implementation
dependent. The Sun HS JVM may do one thing while the HP JVM do another and
IBM's yet a third. At least, that's how I see it. Do this make sense (or
not) to others?

Gary

-----Original Message-----
From: Hope, Matthew [mailto:Matthew.Hope@capitalone.com] 
Sent: Thursday, April 24, 2003 1:51 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [All] Compiler Warnings/What's left for a release? [WAS: [Poo
l] C ompiler Warnings/What's left for a release?]

>From: Gary Gregory [mailto:ggregory@seagullsw.com] 
>Sent: 23 April 2003 21:04
><snip>
>
>The performance issue is a consequence of the JLS specification for inner
>classes. All java compilers use these access methods.

Out of interest - is their anything preventing hotspot jvm's from inlining*
these method calls? And do you know if any do?

Obviously does not change the malicious code issue but I would think most
people were more concerned with performance issues...

Matt

* or otherwise optimising away a significant part of the cost
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message