Testing Java application to uncover Java Virtual Memory – JVMs compatibility:
Often problems with JVMs are related to incompatible configurations or versions with the application that uses the JVM or the environment for which the JVM is running. You might be facing a problem where you are using a Java Applet application that utilizes a JVM to launch. Remember that whenever you upgrade your application’s backend Java code, in some cases, you need to also upgrade the JVM on the front end or make sure that the JVM is compatible with the application’s J2SE version. Your application might be running J2SE5.0 which made changes in both the actual java language and the JVM as well. Though your application might still function properly with an older version of the JVM, the latter will still affect the performance of your java application. To avoid getting an UnsupportedClassVersionError or degradation in your JVM, make sure to consult with your application’s vendor or read the installation manual. The case might be the opposite where you use a newer version of the JVM and the actual java code of the application is of an older version.
During your first functional Java testing of a one user test in a specified environment, be sure to check your JVM logs. Whenever you launch your Applet or Java application, if the JVM is not installed, the application will ask you and direct you to install it. After you download and install the JVM and launch the Java application, the JVM will launch and show as an icon in your system tray. You can right click on the JVM icon to view the log or you can find the log in the
%userprofile% Application DataSunJavaDeploymentlog . By default the log file will show you any major errors but not any detailed ones.
If you have upgraded your JVM, Java parameters from client or server side and/or the Java code itself then you need to test it with few users and for longer period to ensure the compatibility, endurance and performance of the JVM. Java testing takes time and finding the problem takes time as well. Also, Java testing should be done from the front end like a real user to uncover problems without skipping any application layer. Many Java testers choose AppLoader to automate their actions to reflect real user actions and test the compatibility of their JVM across different OS and different browsers. AppLoader’s flexibility allows you to run different tests (functional, endurance, smoke, etc…) with one or multiple users at the same time. This automation process allows you to fire the java test whenever needed across the different browsers and OS.
Now that you have setup your test and ran it for multiple users, you might discover that some users are still facing problems while others aren’t. For example, one issue would be that the application is still using some configurations or cache of the older version of JVM before the upgrade. Java testers should do the following:
1. Clear JVM cache from the Java Control Panel
2. Make sure there is only one JVM version installed and that the old installer is removed
3. Make sure that your application’s JVM parameters in the Java logging properties point to the correct JVM version
4. Adjust the configuration in the Java logging Properties
5. Re-run the java test
Adjusting configurations or testing the java application is not a onetime process, every time a patch is installed or a backend, tomcat or any java webserver or a middle-ware configuration change is made, it will affect the compatibility of your JVM or the application itself. Having a unified and standard automated repeated testing like a real user from the front end with many users across different platforms and browsers will save you time and reduce your overall defect rate and risk throughout your java testing.