They can readily inline them in the same class (so all private methods
qualify). Otherwise, you don't really know what the code will be until
the class is loaded. A sufficiently-clever classloader can do amazing
things, but usually this sort of trick is done later, Just-In-Time
compilers that
I had to do some research on that pesky final keyword. Here's what I now
understand:
Use final for classes that should not be extended and methods that should
not be overridden (all methods of a final class are implicitly final). If
you use final in an attempt to increase performance, you lose
On Jan 28, 1:53 am, Tim Russell t...@jatra.co.uk wrote:
I believe final local variables are usually placed on the heap for extended
lifetime (for use in inner classes), so is their a runtime overhead rather
than using simple locals (which use Dalvik registers)?
Doing something like this:
The only time you need to use it is when the variable is referenced by
an anonymous inner class (the compiler will let you know).
is this a documented feature of Java? seems like a bit of a hack
override of final to me.
much nicer to use a class member, IMHO.
--
I'm not sure about DalvikVM, but some compilers take advantage of
'final'.
E.g.
Final variables can be put in registers of the CPU without worrying
that they may change during execution (constantly moving variable-
values back and forth from memory to registers could be omitted for
'final' vars).
you might use method declared variables to help with scope... if you know a
variable is only used in the method, why declare public.. keep it in the
method and let the method clean it up at the end.
On Fri, Jan 29, 2010 at 3:32 PM, Jason Proctor
jason.android.li...@gmail.com wrote:
The only
I am a bit rusty on the use of final methods.. I do know they cant be
extended.. but I also thought that modern JVMs inline final methods or
something..to help speed them up?
On Fri, Jan 29, 2010 at 3:47 PM, Streets Of Boston
flyingdutc...@gmail.comwrote:
I'm not sure about DalvikVM, but some
yeah i'm clear on why final's more conventional uses, but does it
really change the scope of a variable so that it sticks around for an
anonymous class to use it at an unspecified later time -- onClick()
etc? doesn't seem right somehow.
maybe i should read the documentation! lol...
I am a
On Jan 29, 3:55 pm, Jason Proctor jason.android.li...@gmail.com
wrote:
yeah i'm clear on why final's more conventional uses, but does it
really change the scope of a variable so that it sticks around for an
anonymous class to use it at an unspecified later time -- onClick()
etc? doesn't seem
If you compile this with javac, it will complain:
Blah.java:6: local variable x is accessed from within inner class;
needs to be declared final
private int i = x;
^
1 error
If you change the declaration to final int x = 27, it succeeds.
yes, i
On Jan 29, 3:47 pm, Streets Of Boston flyingdutc...@gmail.com wrote:
I'm not sure about DalvikVM, but some compilers take advantage of
'final'.
E.g.
Final variables can be put in registers of the CPU without worrying
that they may change during execution (constantly moving variable-
values
See below.
On Jan 29, 3:47 pm, Streets Of Boston flyingdutc...@gmail.com wrote:
I'm not sure about DalvikVM, but some compilers take advantage of
'final'.
E.g.
Final variables can be put in registers of the CPU without worrying
that they may change during execution (constantly moving
Definitely good advice, if we're confusing 'field' and 'variable'. If
not, then you're stating a tautology, which is even better! :)
On Jan 29, 3:48 pm, Kevin Duffey andjar...@gmail.com wrote:
you might use method declared variables to help with scope... if you know a
variable is only used in
Yes, or given the background of the language designers, CPA. And the
compiler has to figure this out in order to give the error message --
and even in the error case, there are several trivial ways to
transform the code to be equivalent. (It's a mite more difficult to
make sure debuggers know what
14 matches
Mail list logo
