Compile this.. (any package you like, or no package at all)
public class Rethrow {
public static void unchecked(Throwable t) {
t=t;
}
}
javap reports the byte code as..
public static void unchecked(java.lang.Throwable);
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
Christian Catchpole wrote:
> Compile this.. (any package you like, or no package at all)
>
> public class Rethrow {
> public static void unchecked(Throwable t) {
> t=t;
> }
> }
>
> javap reports the byte code as..
>
> public static void unchecked(java.lang.Throwable);
> Code:
>
yeah, don't take too much notice of that. i noticed that if you
disassemble a "throw", it doesn't have a return. but the a=a does.
maybe its requirement of bytecode that a method that does return,
finishes with return byte code. but its like Java strings being a
char array with a size. there's
Oops. i totally misread your comment.. yeah, i was surprised as
well. :)
On Aug 26, 7:53 pm, Fabrizio Giudici
wrote:
> Christian Catchpole wrote:
> > Compile this.. (any package you like, or no package at all)
>
> > public class Rethrow {
> > public static void unchecked(Throwable t) {
> >
of course it's need a return if it's NOT being JITted... im talking a
load of crap tonight.. aload_0 f crap.. get it! :)
On Aug 26, 8:09 pm, Christian Catchpole
wrote:
> yeah, don't take too much notice of that. i noticed that if you
> disassemble a "throw", it doesn't have a return. but the a=
i guess nowadays javac translates almost literally the source code
into bytecode, leaving the hard work for JIT
On Wed, Aug 26, 2009 at 7:29 AM, Christian
Catchpole wrote:
>
> of course it's need a return if it's NOT being JITted... im talking a
> load of crap tonight.. aload_0 f crap.. get it! :
uot;
Sorry if this was off-topic.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
From: Marcelo Fukushima
To: javaposse@googlegroups.com
Sent: Wednesday, August 26, 2009 1
ed into
> getOne() + "two three"
>
> Sorry if this was off-topic.
>
> Alexey
> 2001 Honda CBR600F4i (CCS)
> 1992 Kawasaki EX500
> http://azinger.blogspot.com
> http://bsheet.sourceforge.net
> http://wcollage.sourceforge.net
>
>
> ____________
> From
Subject: Re: Optimizations? was Re: [The Java Posse] A quick and dirty way to
throw unchecked exceptions
im guessing its because of the "receiving" side of the append
function? have not tried, but id hope that
"two " + "three " + one()
would become
"two three &qu
My class did have debug symbols. I guess no point having symbols that
don't point to anything.
On Aug 27, 3:32 am, Marcelo Fukushima wrote:
> i guess nowadays javac translates almost literally the source code
> into bytecode, leaving the hard work for JIT
>
> On Wed, Aug 26, 2009 at 7:29 AM, Ch
Alexey Zinger wrote:
> There are quite a few optimizations with strings, for sure. Such as
> replacing concatenation using "+" operator with StringBuilder and
> concatenation of literals with a single literal (*).
>
> There's an interesting exception to that rule. The following will
> work as
hmm.. think you missed the point there peter. "two " + "three" ==
"two three" regardless of what comes before it. But I think i might
know why the optimizer picks up
"one " + "two " + "three"
but not
getOne() + "two " + "three"
it probably sees this..
(("one " + "two ") + "three")
==
(("one
I did miss the point (or in fact the little word "not").
I think your theory is probably right, although in the absence of
arbitrary operator overloading it seems quite clear what the type of
(getOne() + "two ") is and since string concatenation is associative it
would be a valid optimization.
Maybe I missed your point :) I thought the original question was why
getOne() + "two " + "three"
doesnt become
getOne() + "two three"
even if it was
getTotallyRandom() + "two three"
On Aug 27, 9:07 pm, Peter Becker wrote:
> I did miss the point (or in fact the little word "not").
>
> I thi
I thought your comment to my post was quite appropriate -- I really had
misread Alexey's post.
But maybe we are just entangled in some weird kind of dance, missing
each others point until the end of time. Or something.
Bedtime.
Peter
Christian Catchpole wrote:
> Maybe I missed your point
yes that's.. i have a habit of posting.. re-reading.. and doh!-ing :)
On Aug 27, 10:40 pm, Peter Becker wrote:
> I thought your comment to my post was quite appropriate -- I really had
> misread Alexey's post.
>
> But maybe we are just entangled in some weird kind of dance, missing
> each others
I can confirm that the compiler is completely unaware of multi-arity
operators (the notion that + takes 2 OR MORE elements - it just takes
2 elements, no more, and multiple applications are merely this notion
chained), and that these are always resolved in a strict left-to-right
fashion.
You can
That's how all compilers I've seen do things. It's all just parser
rules and associativity that maps to unary or binary tree nodes which
then is collapsed in the desugar/optimizer phase. Nothing unusual
about that, classic divide and conquer I'd say.
/Casper
On 27 Aug., 14:45, Reinier Zwitserloo
+ is a binary operator. In mathematics it tends to be associative, i.e.
it doesn't matter if you do (a+b)+c or a+(b+c), but it would be resolved
by combining two values at a time.
The Java compiler does do the right thing, but by allowing mixed type
operations with semantics depending on the t
19 matches
Mail list logo
