1 |
Okay, that helps. |
2 |
|
3 |
I'm not a compiler expert but here's a couple factoids: 1) we're always |
4 |
working to improve performance, 2) the compiler team is always working |
5 |
on improving the compiler (fix bugs etc), 3) the generated byte codes |
6 |
can either exhibit certain bugs or performance gains/losses ... hence, |
7 |
hence I expect/assume the byte codes output to vary somewhat from |
8 |
release to relase. |
9 |
|
10 |
I can't say how much or what specifically that would be. |
11 |
|
12 |
- David |
13 |
|
14 |
|
15 |
Caster wrote: |
16 |
> Greg Tassone wrote: |
17 |
> |
18 |
>> I think this statement is a little too broad to be considered correct. |
19 |
>> The compiler can (and often does) make changes to the resulting binaries |
20 |
>> that may be VM-level specific (e.g., targeted for a 1.5 VM). Consider |
21 |
>> the "-target" argument for javac, for example, which "Allow[s] javac to |
22 |
>> use 1.5 specific features in the libraries and virtual |
23 |
>> machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ). |
24 |
> David Herron wrote: |
25 |
> |
26 |
>> er... Caster, the bytecode does vary based on the compiler. And the |
27 |
>> class file format has varied a small amount from release to release with |
28 |
>> the 1.5 class file format being the most different. |
29 |
>> |
30 |
>> This is, as I understand it, the crux of the problem you guys are seeing |
31 |
>> with adopting 1.5 ... yes? |
32 |
> |
33 |
> Sorry, I wasn't clear enough. I didn't mean the class file format which |
34 |
> is indeed different and causes problems. I was trying to ask if there |
35 |
> are any (the compiled bytecode performance?) gains of using 1.5 compiler |
36 |
> for 1.4 source (without specifying --source and --target 1.4). This |
37 |
> source won't use any 1.5 specific features, but you say the bytecode |
38 |
> still can somehow? |
39 |
> |
40 |
> Caster |
41 |
> |
42 |
> |