Why in the world would the parent post be modded "troll"?
Jeepers... if that info hadn't been passed on to me from a helpful fellow on #mozilla, I'd probably still be struggling with it... I figured it might help someone else.
...lots of those out there already; more on GForge here.
Splitting up the project load makes sense to me; that way one site - SourceForge - doesn't have to bear the full load. Also, it lets folks do custom things to make their site more useful - like Graal.
Re:Being able to decompile code....
on
Decompiling Java
·
· Score: 1
Hm. Yup, that makes sense. Thanks much!
Tom
Re:Being able to decompile code....
on
Decompiling Java
·
· Score: 1
> remove the enclosed code.
Hm. It's odd that we see this:
[tom@hal tmp]$ cat Test.java && javac Test.java class Test {
void foo() {
final int x = 3;
if (false) {
x = 2;
}
} } Test.java:5: cannot assign a value to final variable x
x = 2;
^ 1 error [tom@hal tmp]$
If the code in the "if" body is going to be dropped, why complain about the assignment?
Re:Being able to decompile code....
on
Decompiling Java
·
· Score: 1
> JLS requires [...] constant propagation
Hm. I knew that the JLS required that in some circumstances - i.e., so that a switch statement can switch on a static final. What's the actual requirement, though? For example:
int x = 2; int y = 4 * x;// can be int y = 4 * 2; int z = f(x, y);
Is a conforming compiler also required to make that transformation?
Re:Being able to decompile code....
on
Decompiling Java
·
· Score: 1
> the two should be equivalent on a > machine level.
Yup, for assembler, that makes sense. But for Java bytecode, the explicit comparison is resulting in this:
10: iconst_1 11: if_icmpne 14
vs
10: ifeq 13
So there's a least one extra instruction in there. Of course, again, what the JIT compiler might do with this is something else entirely.
Re:Which is really surprising to me
on
Decompiling Java
·
· Score: 1
> to produce identical simplified bytecode.
Yeah. Another result - this code results in the "if" statement body being optimized away:
class Test {
void foo() {
if (false) {
System.out.println("boo!");
}
} }
but this doesn't:
class Test {
void foo() {
boolean b = false;
if (b) {
System.out.println("boo!");
}
} }
But who knows - the JIT compiler may discard those bytecodes at runtime. Hard to say...
Re:Being able to decompile code....
on
Decompiling Java
·
· Score: 2, Informative
> Is there a good reason why it doesn't?
The Java compiler does some optimization - for example, when given this code:
class Test {
int x = 2 + 2; }
it does algebraic simplification to reduce that assignment to an aload followed by a iconst_4 instruction. And it does some constant propagation so that this:
class Test {
private static final int X = 2;
int y = X + X; }
also gets simplified to the aload/const sequence. I guess it's just some choices the compile designers made on which things were more feasible to attack.
Being able to decompile code....
on
Decompiling Java
·
· Score: 5, Interesting
...can be handy when trying to figure out the advantage of one coding idiom over another. On the PMD project (a Java static analysis tool) there was a discussion yesterday about code like this:
Anyhow, decompiling the classfile with "javap -c" shows that a couple of instructions get eliminated by dropping the explicit comparison to "true". So the classfile gets smaller, it loads faster, and (unless the JIT compiler is smart enough to do constant propagation on that conditional) it'll run faster, too.
There are a bunch of distributed agents scattered around lots of machines; some use more resources than others, and the system moves them from machine to machine in response to high loads. Nifty stuff, and open source - BSD licensed!
> People can write some scary code and then > just blame it on the engine.
Yup. There's a really good article by Stephane Faroult on OnLamp about writing better SQL... it's right here.
After reading that article, I went through some code I'd written and found some places where I was using DISTINCT incorrectly in exactly the way he described.
> After reading that, I think Ruby has a > long way to go in terms of security.
FWIW, Chad doesn't maintain the Ruby core - he was writing a chapter of the book. So his laptop getting stolen was a major hassle for him, but it didn't endanger the Ruby CVS repository.
Slashdot Mirror
FWIW, there's also a nice SQLite binding for Ruby:Good stuff!
Interesting, and thanks! FWIW, I've got a fresh Fedora Core 3 install and it has freetype 2.1.9 installed...
Why in the world would the parent post be modded "troll"?
Jeepers... if that info hadn't been passed on to me from a helpful fellow on #mozilla, I'd probably still be struggling with it... I figured it might help someone else.
...put "ac_add_options --disable-freetype2" in your .mozconfig. Otherwise you'll get errors in grx/src/freetype.
...lots of those out there already; more on GForge here.
Splitting up the project load makes sense to me; that way one site - SourceForge - doesn't have to bear the full load. Also, it lets folks do custom things to make their site more useful - like Graal.
...but JDK 1.4 certainly had a lot of duplicate code.
...a torrent of all the presentations is here.
Anyway, he had some interesting things to say about micropayments; a summary of his talk is at the bottom of the page in Jim Weirich's blog here.
I should add that the book was published in 2001, so it's not exactly cutting edge. But most of the info still applies...
...SSL and TLS, which includes an introductory that has a nice overview of encryption concepts and techniques.
The explanation of stream vs block ciphers is especially good, with nice examples showing how each technique works.
...advocacy list about Oxford switching from Ingres-based apps to PostgreSQL - right here.
UTILITY PLUG: Here's an open source PostgreSQL query analyzer
Hm. Yup, that makes sense. Thanks much!
Tom
Hm. It's odd that we see this:If the code in the "if" body is going to be dropped, why complain about the assignment?
Hm. I knew that the JLS required that in some circumstances - i.e., so that a switch statement can switch on a static final. What's the actual requirement, though? For example:Is a conforming compiler also required to make that transformation?
> machine level.
Yup, for assembler, that makes sense. But for Java bytecode, the explicit comparison is resulting in this:vsSo there's a least one extra instruction in there. Of course, again, what the JIT compiler might do with this is something else entirely.
Yeah. Another result - this code results in the "if" statement body being optimized away:but this doesn't:But who knows - the JIT compiler may discard those bytecodes at runtime. Hard to say...
The Java compiler does some optimization - for example, when given this code:it does algebraic simplification to reduce that assignment to an aload followed by a iconst_4 instruction. And it does some constant propagation so that this:also gets simplified to the aload/const sequence. I guess it's just some choices the compile designers made on which things were more feasible to attack.
Anyhow, decompiling the classfile with "javap -c" shows that a couple of instructions get eliminated by dropping the explicit comparison to "true". So the classfile gets smaller, it loads faster, and (unless the JIT compiler is smart enough to do constant propagation on that conditional) it'll run faster, too.
...for a while - witness their use of Tomcat and MySQL in GoLive as far back as 2002.
...is hosting BitTorrents of the SuSE 9.2 LiveCDs here. 1.3 TB transferred on the DVD so far!
...and figure out which ones are being run most frequently with PQA. Works with PostgreSQL, too!
...Cougaar.
There are a bunch of distributed agents scattered around lots of machines; some use more resources than others, and the system moves them from machine to machine in response to high loads. Nifty stuff, and open source - BSD licensed!
> People can write some scary code and then
> just blame it on the engine.
Yup. There's a really good article by Stephane Faroult on OnLamp about writing better SQL... it's right here.
After reading that article, I went through some code I'd written and found some places where I was using DISTINCT incorrectly in exactly the way he described.
...before blaming MySQL! Ha ha!
Er, anyhow, as an apology, here's an open source SQL analyzer.
> After reading that, I think Ruby has a
> long way to go in terms of security.
FWIW, Chad doesn't maintain the Ruby core - he was writing a chapter of the book. So his laptop getting stolen was a major hassle for him, but it didn't endanger the Ruby CVS repository.