Java code compiled using an older JDK will not work properly with a newer JRE/JVM

Question

Since this became long and rather specific, I thought that it might be a good idea to insert a few lines to clarify the question and why this may be useful for others. Please keep in mind this is my first question. If I have included too little or too much information, please let me know.

The question that I would like to ask is:

Are there portions of Java that will cease to work as expected across the various versions of Java due to library code changes or security patches? Can it be determined if this is the case with my issue?

I believe that this information will be helpful to other programming novices by helping them to better understand the changes that take place when the Java language evolves to its newer versions. I have found a question on this site that goes over the changes to the versions of java from 1.5 to versions 1.6 and 1.7 ( New features in JDK 1.6 and 1.7 ) but I have not been able to identify a reason that my code is not working properly.

I have written a program that can retrieve values from a Windows system using a Runtime object to execute command line requests. The information that is retrieve are mainly registry key values. After retrieving this information, I have the program create a File object and output the retrieved information to an HTML file that it creates. I can create and run an executable JAR file on each of the respective versions (1.5 and 1.7). When executing the 1.5 JAR on a 1.7 system however, the resulting HTML is created but remains blank. Another portion of the program that stops working is its debug option. I created a debug option that looks for a file called debug.txt in the same directory that the JAR is located. The 1.5 version does not activate the debug option on 1.7 though.

EDIT

Summary of issue:

My program should be creating an HTML file from the information that it retrieves from the system. At this time, when the 1.5 compiled version is run with java version 1.7, it simply creates a blank HTML file rather than one filled with information. Another change is that the program usually generates a debug log file with the string created as seen in the first code segments catch block. This should be done when the file debug.txt exists, but does not.

EDIT

I researched the issue and know that Java is intended to be backwards compatible. I have not been able to locate any issue that might point to a version issue. I believe that I likely have something that is wrong with my code when applied across versions.

I have included some code to the sections that are not working as expected.

try{
    File file = new File("C:\\Users\\" + System.getProperty("user.name") + "\\Desktop\\Results.html");

    FileWriter outFile = new FileWriter(file);
    PrintWriter out = new PrintWriter(outFile);

    out.println("A large" + amount + "of concatenated" + strings);
    out.flush();
    out.close();
}catch(IOException e){
    //debugErrorString currently has global scope
    debugErrorString += ("*************************************************************\r\n" + 
                                "There was an issue with writting the results.html document" + e + 
                                "\r\n**********************************************************\r\n\r\n\r\n\r\n");
}

public static void writeDebugLog(){
    try{
        final String debugLogFile = "C:\\Users\\" + System.getProperty("user.name") + 
                                                "\\Documents\\WorkstationDebugLogFile.txt";

        PrintWriter out = new PrintWriter(new FileWriter(debugLogFile));

        //registry currently has global scope
        out.println(debugErrorString + "\n\n\n" + registry.getDebugString() + "\r\n");
        out.flush();
        out.close();

    }catch(Exception e){
        System.out.println(e);
    }
}

Additional information:

1. This code was written, codded, compiled, and packaged into a JAR file using Eclipse
2. Testing was performed on two Windows 7 x64 systems
3. I realize that creating code specific to an operating system is against the goal of Java.
   • The application that this program retrieves information for will only utilize Windows operating systems.
   • I also require information from the Windows registry. Not sure how I would do this and maintain Javas cross platform functionality.
4. I allowed Eclipse to generate the manifest file automatically
5. I am relatively new to creating Java programs. I will greatly appreciate any comments
   that help me address any issues with my coding or question writing for this site.

Thank you for taking the time to review this information and my question.

EDIT

Additional information gained from suggestions.

Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
    Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range:-1
    at java.lang.String.substring(String.java:1958)
    at com.McKesson.WorkstationDiagnostic.WorkstationDiagnostic.createPage(WorkstationDiagnostic.java:321)
    at com.McKesson.WorkstationDiagnostic.WorkstationDiagnostic.main(WorkstationDiagnostic.java:125)
    ... 5 more 

The line in question is:

if(new File(envVar.substring(envVar.indexOf("C:\\oracle\\product\\"), envVar.indexOf("\\bin;C:\\") + 4)).exists())

While I am not certain why the sub string is not found only when crossing versions, I now have something to look at. I will have to deal with this sub string not being found and exceeding the limits of the searched string, as well as determining why this issue has ocured when crossing versions.

This leads me back to the original question as well. Why would something like this not work only when executing with a newer version?

EDIT

EDIT

Based on the comments, I have made the following changes:

if(new File(envVar.substring(envVar.indexOf("C:\\oracle\\product\\"), envVar.indexOf("\\bin;C:\\") + 4)).exists())

has been changed to

String tokens [] = envVar.split(";");

    for(int i = 0; i < tokens.length; i++)
        if(tokens[i].contains("C:\\Oracle\\Product") && new File(tokens[i]).exists())

This should also remove the possibility of throwing the array index error that was seen. I am also thinking that the second test will not be performed if the first test is false.

The goal that I was attempting to reach with this line was to determine that the environmental variables contained an actual location of the Oracle bin directory.

If there are any suggestions to improve upon my resolution, please let me know.

EDIT

Answer 1

As there so many comments:

One thing worth checking: compile the application with both Java versions . Then you can check with Java 7 runtime whether there is a difference.

In general:

1. Java indeed is strongly backwards compatible.

1a. However: old Applets not long ago get problems due to stronger security measures.

1. Seeing the code I doubt a Java version incompatibility is involved. Still...

Answer 2

Java is strongly backwards compatible. When an issue does arise, it is likely due to a bug in the created code. In the recent past, there were issues with older Applets due to stronger security measures. If you are experiencing issues with your code, you should ensure that you are utilizing proper debugging techniques, before reaching the conclusion of Java version issues.

For This particular issue, there was a bug with the way that the environmental variable was being read. By searching for a sub string ending with "\\bin" there was the possibility of reaching this common string prior to the starting string of "C:\\oracle\\product\\". This would throw an error since the end of the requested sub string would be before the start. The reason that this resulted in the behavior seen would be due to the placement of the JDK 1.5 within the environmental variable.

This issue was also missed due to improper debugging practices. While an IDE (Eclipse in this case) is useful for writing and debugging code, it is often the case that more useful information can be retrieved from running programs from the command line. In this example, the program executed properly when run from within Eclipse, but not as a JAR. Therefore, there was no System output to be reviewed when the JAR was executed with a double clicked. Running the JAR with the use of a command prompt allowed for the errors to have a visible space to be reviewed in.