Quote:
Originally Posted by knc1
For instance:
./usr/java/lib/sunrsasign.jar in META_INF/MANIFEST.MF
Code:
Manifest-Version: 1.0
Created-By: 1.3.1_19 (Sun Microsystems Inc.)
./opt/amazon/ebook/booklet/MobiReader.jar in META_INF/MANIFEST.MF
Code:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: Blackdown-1.4.2-02 (Blackdown Java-Linux Team)
Main-Class: com.amazon.ebook.booklet.reader.Reader
I.E: Mixed version code is "factory stock".
I suppose one could script a look-up of all the *.jar files and "vote" on which answer is correct, or ;
Use the version known to work (1.4). |
I think you're getting something terribly wrong here.
First, you're only looking at metadata. The "Created-by" entry is purely informational, and could be set to "My favorite pink plush toy, version 2007". It doesn't matter. The only thing that actually matters is the class version embedded in the
class file - specifically the major_version and minor_version entries.
Second, the JVM is (of course) downward-compatible. So a Java 7 JVM can of course run bytecode that was produced for a 1.0 JVM. The whole point of the JVM (and its versions) is that new JVM versions (may) include new opcodes, but they will never remove existing ones.
The JVM is exactly what its name says: a virtual machine. And for those who are interested, there is a very clear
Specification.
I'm digressing, I know... but: in fact, the JVM and the Java language are not as tightly coupled as many people think. It is by no means a necessity to write code for the JVM in the Java language. (If you're more at home in the Windows world, compare it to the .NET framework - this is exactly the same concept as the JVM).
There are lots of other languages out there which can compile to Java Bytecode - maybe the most famous example is
Scala.
Heck, even I wrote a compiler for a simple language, which produced (actually working! yay!
) Bytecode, in the "Compilers" course at University.