Compiled byte code from version a and version b of some external library?

Hi,

We are having a bit of debate in our office about compiling code against to different external libraries.

i reckon the compiled bytecode should be the same, but there are differences of opinion so i thought i would come here and see what people thought.

lets say i am compiling my code using jar coollib1.0,

lets also assume i use the jar in all possible ways, extends classes, implement its interfaces, use methods and so on...

Now cool lib comes out with coollib1.2, and our codecompiles using this new jar. Is the actual compiled bytecode the same or not?

Thanks a Mill,

Anthony

[644 byte] By [Anthony-Brewa] at [2007-10-2 18:21:30]
# 1
> > Now cool lib comes out with coollib1.2, and our code> compiles using this new jar. Is the actual> compiled bytecode the same or not?> I meant to say is our compiled bytecode the same, not the external libraries bytecode...
Anthony-Brewa at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 2
I would think maybe so, maybe not, but probably it would be.One way to be really sure is to actually try it with a simple sample and compare the generated binaries.
Lokoa at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 3
If you use any final scalar values from the library for case values in switch statementsand these values have changed (potentially breaking backward compatibility)the bytecode will differ.
tschodta at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 4
Not forcibly. If there was a foo class with a bar(Object o) method in 1.0 and a bar(String s) was added in 2.0, then invoking foo.bar against a String will resolve differently.
BIJ001a at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 5

yes, but that resolution is done runtime, not compile time.

Code compiled against the 2.0 library may still work when running against the 1.0 library if it doesn't use any of the new functionality.

That's how javac works as well with the -target flag, the rt.jar you compile against doesn't get replaced with an earlier version after all.

jwentinga at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 6
> yes, but that resolution is done runtime, not compile> time.No, resolution of overloaded methods is done at compile time. Resolution of overridden methods is done at run time.
ejpa at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 7

Hey Guys,

Thanks a Million for this, I intended to write a simple example but I managed to mangle my right hand about a month ago!! I will do this example and probably put it up somewhere over the weekend. I will come back here and let you know how I got on.

Youre input really gives me some good ideas, and I will let you know how I get on and post a link.

All the Best,

Anthony Brew

Anthony-Brewa at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...
# 8

> > yes, but that resolution is done runtime, not

> compile

> > time.

>

> No, resolution of overloaded methods is done at

> compile time. Resolution of overridden

> methods is done at run time.

and that's part of the problem.

You're compile time resolution will now cause a method to be picked up that is the wrong one (or may even be unavailable in the new class version or at another memory address).

Or you may have a runtime resolution built into the compiled code that when compiled against the new version would change to a compile time resolution (and maybe cause a compiler error because of that).

jwentinga at 2007-7-13 19:42:05 > top of Java-index,Developer Tools,Java Compiler...