JVM independent code

[jay akhawri]

Hi,

I am working to build a small (launcher based) JDBC tool which users will be running on different JVM ranging from 1.3 to latest.

following are the major issues:
1. JVM is not known at the runtime.
2. Users should not be needed to re-compile the code based on the JVM runtime.

I am looking for a best practice and/or implementation sample which can cover this. I am also looking for a documentation on a launcher application which does all the precheck to successfully launce the application.

In short, I want to make sure that at any cost the application is launched successfully.

thanks

~Jay

[Marco Ehrentreich]

Hi Jay,

unfortunately I have to say that I don't have practical experience with this compatibility issue but I think you won't have much better options than to simply write your application to be downward compatible with Java/JVM version 1.3. Or would you like to write and maintain different versions of your application for every possible Java version?

Marco

[Ulf Dittmer]

Just make sure you compile with "-source 1.3 -target 1.3" and you should be fine. Of course, testing it on a 1.3 JVM is also necessary.

[jay akhawri]

Thank you Marco and Ulf for the hints.

Marco Ehrentreich wrote:
Would you like to write and maintain different versions of your application for every possible Java version?

I was thinking in the same direction. However, there are few bottlenecks. The current plan is to Bundle JITTed code (for the various runtimes) with C++ App launcher and run the appropriate version of it.

Bottlenecks
----------------

1. I may add a repository of the JITTED code for the various runtimes. (Currently I am targetting Windows/x86 platform) however, even if I do so I should know what is the default JVM version the user is running.

I tried to build a C++ dll which can use JNI_GetCreatedJavaVMs to get the default JVM but I am not successfull. It always returns Zero.

   
#include "jni.h"
#include <stdio.h>

/*
*Always returns Zero
*/

void main()
{
	JNIEnv* env = NULL;
	JavaVM* jvm = NULL;
	JavaVMInitArgs vm_args;

	jint res;
	JavaVM* vmBuf[10];
	jsize bufLen = 10;
	jsize nVMs;
	vm_args.version = JNI_VERSION_1_6;
	res = JNI_GetCreatedJavaVMs( vmBuf, bufLen, &nVMs );
	printf("Result = %d\n", res);
}

2. If I get pass this hurdle, i might need to find how to emit the JITTed code to execute in target JVM.Which I don't know how.

Am I going in right direction?

~Jay

[Moojid Hamid]

You are making this too complicated for no reason, if you do what Ulf suggested it would run fine in all JVMs 1.3 and up, the newer versions are always backward compatible.

[Ernest Friedman-Hill]

Yeah, this whole thread is very strange. Write only to the earliest API level you need to support, and you're done. The performance of JDBC code is, not surprisingly, limited by database communications; it's not CPU bound. There's no point at all to all this craziness.

[jay akhawri]

if you do what Ulf suggested it would run fine in all JVMs 1.3 and up, the newer versions are always backward compatible.

Ernest Friedman-Hill wrote:Write only to the earliest API level you need to support, and you're done.

Thank you all for the help . Indeed this make sense. Though, I may have to do away with the nice features which requires a minimum JVM version(to give some users the best possible version of the app who can afford better JVM version and yet provide a minmum version to those having lower JVM version.)


~Jay

[Ulf Dittmer]

jay akhawri wrote:Though, I may have to do away with the nice features which requires a minimum JVM version(to give some users the best possible version of the app who can afford better JVM version and yet provide a minmum version to those having lower JVM version.)

You don't necessarily have to do without them, but you need to make sure to use them only in code blocks where you first check that the JVM version is new enough. There are a few System properties that help with this ("java.version" is one of them, I think).

[Marco Ehrentreich]

Hi Jay,

as Ernest said, for this kind of application (at least with the information we know about it) it most probably doesn't really matter for the end user if it's running on a JVM for version 1.3 or 1.6. Maybe it would be easier for you to use newer Java features in your code but that won't make any difference for the user of your application. And of course the benefits you gain when you can use a newer version for _SOME_ application releases are completely wiped out if you have to maintain multiple versions in parallel

In my opinion do what all the others here suggest, too, and make one version which is compatible to Java 1.3 and that's it. If you find any good reasons it's still not to late to think about special versions for users with a newer JVM. But it would be a waste of time to make it more complicated than necessary up front.

Marco

[Ulf Dittmer]

Marco Ehrentreich wrote:Maybe it would be easier for you to use newer Java features in your code but that won't make any difference for the user of your application. And of course the benefits you gain when you can use a newer version for _SOME_ application releases are completely wiped out if you have to maintain multiple versions in parallel.

I wouldn't say that. For JDBC functionality, probably so (although JDBC has gained a number of features since Java 1.3, which included JDBC 2). But for GUI applications in particular it can be handy to use newer features that do make an impact for the user, like the Preferences API and newer Swing skins.

My strategy for dealing with that has generally been for applications that run on older JVMs to be slightly less functional (like not storing preferences), but not to implement all the functionality using the older class libraries. That keeps the overhead for the developer reasonable.

For desktop apps I'd put the baseline JRE version at Java 5 these days. I think it's OK to say to users running something older "Look, the app will run, but it's not a great experience because your software is so old. You may want to upgrade." Note that Java 1.4 has reached EOSL last year, and Java 5 will get there in a few months.