Java version

when they release a new version of Java, like 1.4 <eventually :rolleyes: > do the change anything about the bytecode or JVM at or all or do the just add more classes and deprecate some? an whats the deal w/ Java2?

i assume so, that is the impression that i get when i talk to me lecturer, there are just some more classes added to the main api, and what also would be nice if they managed to speed up java as well.

as for java 2 this is really java 1.2, it goes like this

java 1 - java 1.1

java 2 - java 1.2

java 3 - java 1.3

and so on and so on, why it is structured like this i am not sure but that is the way it seems to be :rolleyes:

r u sure about that Java 1.3 = Java 3 thing?
b/c i think ur wrong because I've heard of Java2 but never 3 or 4 for that matter, nad what woulf Java 1.1 be then?

well yeah from what i have read that is the general assumption that i have come to, i am sorry if i am wrong :)

Changes from version to version are diffrent. Of course the most significant being from 1.1 to 1.2 where the release of 1.2 tripled the number of classes. 1.2 being name Java 2. Java 1.3 is still Java2. Now wether it stays Java2 for the release of the jdk1.4 that remains to be seen.

Having attended JavaOne 2001, I can tell some new features of the latest JDKs (1.3 and 1.4)

* HotSpot(tm) technology. This technology compiles the most often executed bytecode to machinecode, so it runs faster. Furthermore, it is intelligent enough to pre-load classes the VM assumes are going to be instantiated. It is lots faster than the earlier versions of Java
* Separate finetuned VM's for either Server or Client applications. You can give the JRE a command-line parameter to define whether your application was designed as a server or client application.
* Better debugging facilities (still quite basic). Just have a look at the -X... command-line parameters.

It is quite unlikely that Sun decides to change bytecode with newer versions of Java. This would result in incompatibility for running applications compiled with other versions.

Of course, the API is in constant development, of course there will be minor and major changes.

Additionally, Java 2 includes Swing(tm) components in its API. That may be the major difference between Java 1 and 2.

Don't mistake Java 2 for Java 2 EE. J2EE is an Application Server that runs under Java 2.

Anyway, if you're really interested in Java, I think this site would not be the right place for it, you can find more at java.sun.com.

Hey hgroot,


I would think they would have to change the JVM even if they add more packages and classes. Java2 had 52 packages and approximately 100 classes for each of the packages...alot of classes[note: I have read this -- I dont have the time figure exact number:)]. The JVM would have to change to whatever other changes.

Manoj

Hi manoj,

Why would you think that?

Packages and classes are all compiled to the same (type of) bytecode. It's the bytecode that is executed by the JVM, not the classes themselves. Therefore, no changes are needed in the JVM for new classes or packages. Unless Sun has overseen some mandatory bytecode instructions, but I don't believe that.

This is kind of off topic but then again the topic was which Java version. :p Im sure you can get the version number of the jdk from code but you can get other information if you would like also using the public static String getProperty(String key);

For instance to get the OS name the client is currently running you could use String osName = System.getProperty("os.name");
or to get the vendor who coded a particular JVM.
String jvmVendor = System.getProperty("java.vendor");

hey hgroot,

Let me ask you...take for example jdk1.0 which doesnt support swing features and I write something in jdk1.2 that utilizes swings. I will get an error indicating that the package doesn't exist...I know that nearly all JVMs should run java code as long as the bytecode is valid.

1) So my question is...The error message I get...is it done at the jvm side????

2) Secondly, Is the JVM on MacOS different than the Windows version? I Understand that JDk1.2 JVM should run all bytecodes written from jdk1.2 no matter if comes from macOS system or windows, etc.


Manoj

Hi Manoj,

1.
The problem when you execute 1.2 code on a 1.0 / 1.1 VM is that the Swing classes aren't part of the 1.0 / 1.1 standard libraries. 1.2 is downwards compatible with earlier versions, but 1.0 can't be upwards compatible because it was developed earlier (naturally).
Anyway, the JVM would exit with an exception like "ClassDef not found" (for non-existent code), were you to try this...

A 1.0 VM might run swing code, if you copy the swing libraries from 1.2 to 1.0. Keep in mind that bugs may have been fixed in 1.2 which would have prevented Swing code to execute in 1.0 / 1.1. But before trying, why would you ever want to run 1.2 code on (nearly antique) 1.0 or 1.1??

2.
The JVM on a MacOS is different from the Intel platform, because all JVM's are implemented in platform-dependent (machine)code. These different builds of a JVM can also contain different bugs. Besides, there also is the Java Native Interface, wich is an interface to a library of platform-dependent procedures. Some (Swing) methods could use this interface. But, even though it has been implemented in another language, it should still function exactly the same on all platforms.

Indeed, JVM 1.2 code should run on all platforms, but it really depends on the platform-dependent implementation of the VM.


One more thing: Dilenger4 has a good point, the System class is a very useful class for all kinds of advanced things, just look it up in the API. I once used it to produce Windows events (1.1 code, I don't know if it still runs...)

but what if you "brought along" all the SWING classes w/ u to the java 1.0 jvm, wouldn't that work? after all the swing code is in the classes eh? unless the JVM has dramatically changed i don't see why that wouldn't work

Maybe I used too much words, but that's also what I suggested in my post. But don't forget:
- Bugfixes in 1.2 JVM, bugs are still present in 1.0, so Swing code may crash or cause undefined problems.
- Java Native Interface code that may be missing in 1.0.

I haven't tested it and am not planning to do so too. I think it's a waste time.

oh yeah, i was just speaking theoretically, but if anyone tries i'd be interested to know what happens:D

tho prob wouldn't work w/ java 1.0 because it didn't support inner classes which are often used in AWT/SWING event handling, but Java 1.1 and on should work:rolleyes:

I also think it's interesting to see what would happen, just out of curiosity. :)

Copying jars (for example for Swing) can also cause duplicate class definitions. I've had this problem before with copying jars to my webserver /lib. The webserver used XML, so did my application. The webserver had its own XML libraries that were also loaded for my application, but an obsolete version. It's a real challenge to correct such problems. Manually checking jars and deleting class files from them.

Also, in the past I wrote some Native Interface routines. It's nice to know you can use .dll's in Java, though you lose system-independency. But it makes it possible to do everything in Java that was before only possible in C or VB. I haven't kept up with the JDK novelties, but I doubt shutting down a computer can be done in pure Java.

i've heard of that native interface thingy, what is it?

I'll not get into detail about this Java Native Interface.

Just have a look at the files in the /include directory of your JDK.
There's some examples inside those files, too.

Here's the header of the jawt.h file:

/*
* AWT native interface (new in JDK 1.3)
*
* The AWT native interface allows a native C or C++ application a means
* by which to access native structures in AWT. This is to facilitate moving
* legacy C and C++ applications to Java and to target the needs of the
* community who, at present, wish to do their own native rendering to canvases
* for performance reasons. Standard extensions such as Java3D also require a
* means to access the underlying native data structures of AWT.
*
* There may be future extensions to this API depending on demand.
*
* A VM does not have to implement this API in order to pass the JCK.
* It is recommended, however, that this API is implemented on VMs that support
* standard extensions, such as Java3D.
*
* Since this is a native API, any program which uses it cannot be considered
* 100% pure java.
*/